It is trivial to merge the non-MMU and MMU versions of swab.h.
Without a single file "make headers_install" is broken for m68k
(since each of the sub-varients of swab.h are not installed).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
It is trivial to merge the non-MMU and MMU versions of param.h.
Without a single file "make headers_install" is broken for m68k
(since each of the sub-varients of param.h are not installed).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
include/linux/pci-acpi.h:74:
typedef u32 acpi_status;
result is unsigned, so an error returned by acpi_bus_register_driver()
will not be noticed.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Looking at the source, there seems to be a missing * to match my DMI
string. I mean for newer IBM and Lenovo's laptops you match either one
of the following:
MODULE_ALIAS("dmi:bvnIBM:*:svnIBM:*:pvrThinkPad*:rvnIBM:*");
MODULE_ALIAS("dmi:bvnLENOVO:*:svnLENOVO:*:pvrThinkPad*:rvnLENOVO:*");
While for older Thinkpads, you do this (for instance):
IBM_BIOS_MODULE_ALIAS("1[0,3,6,8,A-G,I,K,M-P,S,T]");
with IBM_BIOS_MODULE_ALIAS being MODULE_ALIAS("dmi:bvnIBM:bvr" __type "ET??WW")
Note there's no * terminating the string. As result, udev doesn't load
anything because modprobe cannot find anything matching this (my
machine actually):
udevtest: run: '/sbin/modprobe dmi:bvnIBM:bvr1IET71WW(2.10):bd06/16/2006:svnIBM:pn236621U:pvrNotAv
Signed-off-by: Mathieu Chouquet-Stringer <mchouque@free.fr>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
This driver has been around and used long enough that we can drop the
'experimental'.
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI-WMI isn't experimental anymore, and there are other drivers that now
depend on it that aren't either.
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
This is acer_rfkill_exit() from drivers/platform/x86/acer-wmi.c.
The code frees wireless_rfkill->data again instead of
bluetooth_rfkill->data.
This was found using a code checker (http://repo.or.cz/w/smatch.git/).
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
"I hate `select' and will gleefully leap on any s/select/depends/ patch,
whether it works or not :)"
Andrew Morton
select INPUT is not needed here, because if someone doesn't want INPUT,
he won't want these drivers either.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Like thinkpad_acpi or eeepc-laptop, asus-laptop will
now use "select" instead of "depends on"
for LEDS_CLASS, NEW_LEDS and BACKLIGHT_CLASS_DEVICE
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Restore acpi_generate_proc_event() for backward
compatibility with old acpi scripts.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Restore acpi_generate_proc_event() for backward
compatibility with old acpi scripts.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
It is hardly (if ever) possible but in case of broken _PXM entry we could
reach out of pxm_to_node_map array bounds in acpi_map_pxm_to_node() call.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
There was a misplaced status test (two consequent tests without a
statement in between) in acpi_bus_init for ages. Remove it, since the
function which should be checked (acpi_os_initialize1) has BUG_ONs on
failure paths.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit 5ec5d38a1c.
because it caused spurious dmesg warmings.
We'll implement the check for off-limit ports
in a more clever way in the future.
http://bugzilla.kernel.org/show_bug.cgi?id=12758
Signed-off-by: Len Brown <len.brown@intel.com>
Switch the Asus Pundit P1-AH2 (M2N8L motherboard) to the old ACPI 1.0
sleep ordering by default. Without this it will not suspend/resume
correctly.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Tested-by: Dustin Kirkland <kirkland@canonical.com>
Signed-off-by: Len Brown <len.brown@intel.com>
It fails on the following systems:
- RTL8169sc/8110sc (XID 18000000)
reported by Tim Durack <tdurack@gmail.com> (x86)
- RTL8169sb/8110sb (XID 10000000)
reported by Mikael Pettersson <mikpe@it.uu.se> (ARM)
The patch appeared to work on x86 for the following systems:
RTL8169sb/8110sb 10000000 PCI (EXT)
RTL8110s 04000000 PCI (EXT)
RTL8102e 24a00000 PCI-E (LOM)
RTL8168c/8111c 3c2000c0 PCI-E (LOM)
RTL8168b/8111b 38000000 PCI-E (LOM)
RTL8168b/8111b 38000000 PCI-E (EXT)
The patch exposes two problems:
1) while not completely wrong, mac addresses are not read correctly
from the EEPROM
2) the MAC address registers are not correctly set
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
It shortens the code and fixes the current pci_unmap leak with
padded skb reported by Dave Jones.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ideally, the default should be set to 0 and let the EHCI driver turn
it on as needed. This makes USB usable in the mean time.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Here it is... HIGHMEM for the ARM architecture. :-)
If you don't have enough ram for highmem pages to be allocated and still
want to test this, then the cmdline option "vmalloc=" can be used with
a value large enough to force the highmem threshold down.
Successfully tested on a Marvell DB-78x00-BP Development Board with
2 GB of RAM.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
VIPT aliasing caches have issues of their own which are not yet handled.
Usage of discard_old_kernel_data() in copypage-v6.c is not highmem ready,
kmap/fixmap stuff doesn't take account of cache colouring, etc.
If/when those issues are handled then this could be reverted.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
On xsc3, L2 cache ops are possible only on virtual addresses. The code
is rearranged so to have a linear progression requiring the least amount
of pte setups in the highmem case. To protect the virtual mapping so
created, interrupts must be disabled currently up to a page worth of
address range.
The interrupt disabling is done in a way to minimize the overhead within
the inner loop. The alternative would consist in separate code for
the highmem and non highmem compilation which is less preferable.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The choice is between looping over the physical range and performing
single cache line operations, or to map highmem pages somewhere, as
cache range ops are possible only on virtual addresses.
Because L2 range ops are much faster, we go with the later by factoring
the physical-to-virtual address conversion and use a fixmap entry for it
in the HIGHMEM case.
Possible future optimizations to avoid the pte setup cost:
- do the pte setup for highmem pages only
- determine a threshold for doing a line-by-line processing on physical
addresses when the range is small
Signed-off-by: Nicolas Pitre <nico@marvell.com>
If a machine class has a custom __virt_to_bus() implementation then it
must provide a __arch_page_to_dma() implementation as well which is
_not_ based on page_address() to support highmem.
This patch fixes existing __arch_page_to_dma() and provide a default
implementation otherwise. The default implementation for highmem is
based on __pfn_to_bus() which is defined only when no custom
__virt_to_bus() is provided by the machine class.
That leaves only ebsa110 and footbridge which cannot support highmem
until they provide their own __arch_page_to_dma() implementation.
But highmem support on those legacy platforms with limited memory is
certainly not a priority.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
This is a helper to be used by the DMA mapping API to handle cache
maintenance for memory identified by a page structure instead of a
virtual address. Those pages may or may not be highmem pages, and
when they're highmem pages, they may or may not be virtually mapped.
When they're not mapped then there is no L1 cache to worry about. But
even in that case the L2 cache must be processed since unmapped highmem
pages can still be L2 cached.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
The kmap virtual area borrows a 2MB range at the top of the 16MB area
below PAGE_OFFSET currently reserved for kernel modules and/or the
XIP kernel. This 2MB corresponds to the range covered by 2 consecutive
second-level page tables, or a single pmd entry as seen by the Linux
page table abstraction. Because XIP kernels are unlikely to be seen
on systems needing highmem support, there shouldn't be any shortage of
VM space for modules (14 MB for modules is still way more than twice the
typical usage).
Because the virtual mapping of highmem pages can go away at any moment
after kunmap() is called on them, we need to bypass the delayed cache
flushing provided by flush_dcache_page() in that case.
The atomic kmap versions are based on fixmaps, and
__cpuc_flush_dcache_page() is used directly in that case.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
This is the minimum fixmap interface expected to be implemented by
architectures supporting highmem.
We have a second level page table already allocated and covering
0xfff00000-0xffffffff because the exception vector page is located
at 0xffff0000, and various cache tricks already use some entries above
0xffff0000. Therefore the PTEs covering 0xfff00000-0xfffeffff are free
to be used.
However the XScale cache flushing code already uses virtual addresses
between 0xfffe0000 and 0xfffeffff.
So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.
The Documentation/arm/memory.txt information is updated accordingly,
including the information about the actual top of DMA memory mapping
region which didn't match the code.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
'make randconfig' uses glibc's rand function, and the seed of
that PRNG is set via:
srand(time(NULL));
But 'time()' only increases once every second - freezing the
randconfig result within a single second.
My Nehalem testbox does randconfig much faster than 1 second
and i have a few scripts that do 'randconfig until condition X'
loops.
Those scripts currently waste a lot of CPU time due to randconfig
changing its seed only once per second currently.
Change the seed to be micrseconds based. (I checked the statistical
spread of the seed - the now.tv_sec*now.tv_usec multiplication
there further improves it.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Roman Zippel <zippel@linux-m68k.org>
[sam: fix for systems where usec is zero - noticed by Geert Uytterhoeven]
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Ingo Molnar reported that 'make randconfig' was not covering
choice blocks properly, resulting in certain config options
being left out of randconfig testing altogether.
With the following patch we:
- properly randomize choice value for normal choice blocks
- properly randomize for multi choice blocks
- added several comments to explain what is going on
The root cause of the bug was that SYMBOL_VALID was set on the
symbol representing the choice block so clearing this did
the trick initially.
But testign revealed a few more issues that is now fixed.
Reported-by: Ingo Molnar <mingo@elte.hu>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
CC drivers/parisc/sba_iommu.o
drivers/parisc/sba_iommu.c:1373: error: expected identifier or '('
before '}' token
make[2]: *** [drivers/parisc/sba_iommu.o] Error 1
make[1]: *** [drivers/parisc] Error 2
make: *** [drivers] Error 2
Don't know how this has gone missed for so long... clearly I need
to do builds on my C8000 more often.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* master.kernel.org:/home/rmk/linux-2.6-arm: (23 commits)
[ARM] Fix virtual to physical translation macro corner cases
[ARM] update mach-types
[ARM] 5421/1: ftrace: fix crash due to tracing of __naked functions
MX1 fix include
[ARM] 5419/1: ep93xx: fix build warnings about struct i2c_board_info
[ARM] 5418/1: restore lr before leaving mcount
ARM: OMAP: board-omap3beagle: set i2c-3 to 100kHz
ARM: OMAP: Allow I2C bus driver to be compiled as a module
ARM: OMAP: sched_clock() corrected
ARM: OMAP: Fix compile error if pm.h is included
[ARM] orion5x: pass dram mbus data to xor driver
[ARM] S3C64XX: Fix s3c64xx_setrate_clksrc
[ARM] S3C64XX: sparse warnings in arch/arm/plat-s3c64xx/irq.c
[ARM] S3C64XX: sparse warnings in arch/arm/plat-s3c64xx/s3c6400-clock.c
[ARM] S3C64XX: Fix USB host clock mux list
[ARM] S3C64XX: Fix name of USB host clock.
[ARM] S3C64XX: Rename IRQ_UHOST to IRQ_USBH
[ARM] S3C64XX: Do gpiolib configuration earlier
[ARM] S3C64XX: Staticise s3c64xx_init_irq_eint()
[ARM] SMDK6410: Declare iodesc table static
...
Since now ipaq_model_ops used only for accessing h3600 EGPIOs,
drop it completely and use assign_h3600_egpio() directly.
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Replace all occurences with assign_h3600_egpio.
Also simplify code a bit by replacing couple of if-else
statements with one-line equivalents.
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove unused fields and associated funtions-accesors.
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Right now iPaq h3600's default MTD partitions table is a mess. It has
two #ifdefs with #else, giving total 3 variants, depending on your
kernel config. Replace all this with simple two-partitions scheme
(bootloader + rootfs), that used by both shipped WindowsCE and
most of the linux distributions (Familiar, Angstrom)
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There's no actual code for iPAQ sleeves support in kernel that depends
on this config option.
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The L0s workaround should be moved into a pci quirk and so it is not
necessary in the driver. This update removes the L0s workaround from the
igb driver.
This was the second half of the PCI quirk patch that Matthew Wilcox did
not pick up when he picked up the quirk patch.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The SystemACE driver does not handle an empty CF slot gracefully. An
empty CF slot ends up hanging the system. This patch adds a check for
the CF state and stops trying to process requests if the slot is empty.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
If bio_integrity_clone() fails, bio_clone() returns NULL without freeing
the newly allocated bio.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Stricter gfp_mask might be required for clone allocation.
For example, request-based dm may clone bio in interrupt context
so it has to use GFP_ATOMIC.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
