• Steven King's avatar
    m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips. · eac57949
    Steven King authored
    If we're not connecting external GPIO extenders via i2c or spi or whatever, we
    probably don't need GPIOLIB.  If we provide an alternate implementation of
    the GPIOLIB functions to use when only on-chip GPIO is needed, we can change
    ARCH_REQUIRE_GPIOLIB to ARCH_WANTS_OPTIONAL_GPIOLIB so that GPIOLIB becomes
    optional.
    
    The downside is that in the GPIOLIB=n case, we lose all error checking done by
    gpiolib, ie multiply allocating the gpio, free'ing gpio etc., so that the
    only checking that can be done is if we reference a gpio on an external part.
    Targets that need the extra error checking can still select GPIOLIB=y.
    
    For the case where GPIOLIB=y, we can simplify the table of gpio chips to use a
    single chip, eliminating the tables of chips in the 5xxx.c files.  The
    original motivation for the definition of multiple chips was to match the way
    many of the Coldfire variants defined their gpio as a spare array in memory.
    However, all this really gains us is some error checking when we request a
    gpio, gpiolib can check that it doesn't fall in one of the holes.  If thats
    important, I think we can still come up with a better way of accomplishing
    that.
    
    Also in this patch is some general cleanup and reorganizing of the gpio header
    files (I'm sure I must have had a reason why I sometimes used a prefix of
    mcf_gpio and other times mcfgpio but for the life of me I can't think of it
    now).
    Signed-off-by: default avatarSteven King <sfking@fdwdc.com>
    Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
    eac57949
gpio.c 3.92 KB