Since we solved this by overriding default ->{in,out}put_data
methods in {q40,falcon}ide M68K_IDE_SWAP define can go away.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Now that ide_hwif_t instances are allocated dynamically
the difference between MAX_HWIFS == 2 and MAX_HWIFS == 10
is ~100 bytes (x86-32) so use MAX_HWIFS == 10 on all archs
except these ones that use MAX_HWIFS == 1.
* Define MAX_HWIFS in <linux/ide.h> instead of <asm/ide.h>.
[ Please note that avr32/cris/v850 have no <asm/ide.h>
and alpha/ia64/sh always define CONFIG_IDE_MAX_HWIFS. ]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Add hwif->ack_intr hook and use it instead of hwif->hw.ack_intr.
* Add missing brackets to cris-v32 and powerpc ide_ack_intr() macros.
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Use the new typedef for interrupt handler function pointers rather than
actually spelling out the full thing each time. This was scripted with the
following small shell script:
#!/bin/sh
egrep -nHrl -e 'irqreturn_t[ ]*[(][*]' $* |
while read i
do
echo $i
perl -pi -e 's/irqreturn_t\s*[(]\s*[*]\s*([_a-zA-Z0-9]*)\s*[)]\s*[(]\s*int\s*,\s*void\s*[*]\s*[)]/irq_handler_t \1/g' $i || exit $?
done
Signed-Off-By: David Howells <dhowells@redhat.com>
m68k_handle_int() split in two functions: __m68k_handle_int() takes
pt_regs * and does set_irq_regs(); m68k_handle_int() doesn't get pt_regs
*.
Places where we used to call m68k_handle_int() recursively with the same
pt_regs have simply lost the second argument, the rest is switched to
__m68k_handle_int().
The rest of patch is just dropping pt_regs * where needed.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
