NB: driver is choke-full of code that will break on big-endian; as long
as the hardware is onboard-only we can live with that, but sooner or
later that'll need fixing.
Signed-off-by: Al Viro <[email protected]>
Acked-by: Jeff Garzik <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Andi had removed a bunch of those, but one more had creeped in...
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
not needed and actually breaks build on frv, while we are at it
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
and no, it's not the case of "let's pull bits from underlying architecture"
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
zatm_init() and zatm_start() should be __devinit (the former is
not module init, despite the name - it's a helper for PCI ->probe())
Signed-off-by: Al Viro <[email protected]>
Acked-by: Jeff Garzik <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
GFP_KERNEL allocations in non-blocking context; fixed by killing
an idiotic use of security_getprocattr().
Acked-by: Stephen Smalley <[email protected]>
Acked-by: James Morris <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Martin Schwidefsky wrote:
"s390 does not even need (in|out)b(_p|). I wondered what else from
io.h do we not need. The answer is: almost nothing. With the devres
patch from Al and the dma-mapping patch from Heiko we can get rid of
iomem and all associated definitions."
So we'll just need to replace NO_IOPORT with NO_IOMEM in Kconfig and
kill arch/s390/mm/ioremap.c.
BTW, there's an annoying bit of junk in there - IO_SPACE_LIMIT. We
only need it for /proc/ioports, which AFAICS shouldn't even be there
on s390 (or uml). OTOH, removing that thing would mean a user-visible
change - we go from "empty file in /proc" to "no such file in /proc"...
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
* Split the implementation-agnostic stuff in separate files.
* Make sure that targets using non-default request_irq() pull
kernel/irq/devres.o
* Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive;
allow architectures to turn them off (we needed these symbols anyway for
dependencies of quite a few drivers).
* protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Recent as(1) doesn't think that . terminates a macro name, so getuser.l is
_not_ treated as invoking getuser with .l as the first argument.
arch/m68k/math-emu relies on old behaviour, so it gets a lot of undefined
macros with more or less current binutils.
Note that this behaviour remains in all recent versions and is unrelated to
another binutils problems we used to have for a while (having (%a0)+ parsed
as two arguments). This one is there to stay; it's an intentional and
documented change.
.irp <identifier> <words>
[text]
.endr
expands to a copy of text per each word, with \<identifier> replaced with
corresponding word. Again, what happens depends on whether gas_ident.x
is treated as one or as two tokens; in the former case we'll get old_gas
incremented once, in the latter - twice. The rest is obvious.
Unlike .macro argument list _anything_ is explicitly allowed after
.irp <identifier>; here we are on very safe ground. And yes, it does
work with all gas variants I've got here (including vanilla 2.15, 2.16,
2.16.1 and 2.17, plus debian and FC binutils).
Signed-off-by: Al Viro <[email protected]>
Cc: Roman Zippel <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
readl() et.al. expect iomem pointer, so WTF force-cast it to normal one???
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
On all targets that sucker boils down to memcpy_fromio(sbk->data, from, len).
The function name is highly misguiding (it _never_ does any checksums), the
last argument is just a noise and simply expanding the call to memcpy_fromio()
gives shorter and more readable source. For a lot of reasons it has almost
no remaining users, so it's better to just outright kill it.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
... operations with it are OK as is, but flags & ~0 will have no idea that
this ~0 is meant to be ~gfp_t.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
That code doesn't do what its author apparently thought it would do...
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
missing helper used by arch/i386/mm/highmem.c, which is pulled
into build on that configuration.
Signed-off-by: Al Viro <[email protected]>
Acked-by: Jeff Dike <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Won't build (request_irq()/free_irq()), even if you manage to find an
s390 box with 8250-compatible UART they are expecting.
Signed-off-by: Al Viro <[email protected]>
Acked-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
a) sun4d_boot_one_cpu() should be __cpuinit (called only from
__cpuinit __cpu_up(), for one thing, leads to calls of __cpuinit
functions for another).
b) got externs in arch/sparc/kernel/smp.c to match reality.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
i386 boot/compressed/relocs checks for absolute symbols and warns about
unexpected ones. If you build with modversions, you get ~2500 warnings
about __crc_<symbol>. These suckers are really absolute symbols - we
do _not_ want to modify them on relocation.
They are generated by genksyms - EXPORT_... generates a weak alias, then
genksyms produces an ld script with __crc_<symbol> = <checksum> and it's
fed to ld to produce the final object file. Their only use is to match
kernel and module at modprobe time; they _must_ be absolute.
boot/compressed/relocs has a whitelist of known absolute symbols, but
it doesn't know about __crc_... stuff. As the result, we get shitloads
of false positives on any ld(1) version.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
a) cleanup_module() should be __exit
b) externs should match reality
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
a) registers.h is really needed there
b) include of asm-generic/termios should be under __KERNEL__
c) includes of asm-generic/{memory_model,page} should be under
__KERNEL (nothing in there that would work in userland)
d) a lot of stuff in ptrace.h should be under __KERNEL__.
Signed-off-by: Al Viro <[email protected]>
Acked-by: David Howells <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Kconfig recognizes the end of help text by receding indentation depth.
Recent patch had broken HOST_VMSPLIT_... choice in arch/um/Kconfig.i386 -
all alternatives are interpreted as part of help text now.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
do { } while(0) is not a good imitation of function returning void;
use ((void)0) instead.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
What DMA for 16bit pcmcia card, anyway? We never do request_dma()
there and ->dma_channel never changes since initialization to -1.
IOW, that call is dead code.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
memset() after kmalloc() on size * 8 would better be on size * 8, not
just size; fixed by switching to kcalloc() - it's more idiomatic anyway.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
memset() after kmalloc() on size * 8 would better be on size * 8, not
just size; fixed by switching to kcalloc() - it's more idiomatic anyway.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Al Viro