Red Hat backported pcmcia_loop_tuple() from 2.6.33 to their 2.6.32
kernel (at least in RHEL6) but they use it in hardly anything, and kept
the older configuration mechanism from 2.6.28 involving
pcmcia_get_first_tuple() and pcmcia_get_next_tuple() macros.
Since they didn't change the prototypes of other functions such as
pcmcia_request_window() or pcmcia_map_mem_page() at the same time as
backporting pcmcia_loop_tuple(), our code that uses those functions in
the callback function passed to pcmcia_loop_tuple() fails to compile for
these Red Hat 2.6.32 kernels.
Change the COMEDI_CHECK_PCMCIA_LOOP_TUPLE configuration test to ignore
pcmcia_loop_tuple() if the pcmcia_get_first_tuple() macro is defined.
This will cause our comedi PCMCIA drivers to use the older configuration
mechanism from the 2.6.28 kernel instead of attempting to use the
broken, backported mechanism.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
#
# Check if kernel pcmcia support is new enough to have the pcmcia_loop_tuple
# function.
+#
+# RedHat back-ported it to their 2.6.32 kernel but didn't change prototypes
+# of pcmcia_request_window() and pcmcia_map_mem_page() at the same time.
+# They kept the older mechanism using pcmcia_get_first_tuple() and
+# pcmcia_get_next_tuple(), so ignore backported pcmcia_loop_tuple() if
+# pcmcia_get_next_tuple() is defined.
AC_DEFUN([COMEDI_CHECK_PCMCIA_LOOP_TUPLE],
[
AC_MSG_CHECKING([$1 for pcmcia_loop_tuple function])
if [grep -q 'int[[:space:]]\+pcmcia_loop_tuple[[:space:]]*(' "$1/include/pcmcia/ds.h"] 2>/dev/null ; then
- AC_MSG_RESULT([yes])
- $2
+ if [grep -q '^[[:space:]]*#[[:space:]]*define[[:space:]]\+pcmcia_get_first_tuple(' "$1/include/pcmcia/ds.h"] 2>/dev/null ; then
+ AC_MSG_RESULT([yes but ignoring backport])
+ $3
+ else
+ AC_MSG_RESULT([yes])
+ $2
+ fi
else
AC_MSG_RESULT([no])
$3