Re: [PATCH 1/2] gpio: gpio-generic: Fix bug in big endian bit conversion

From: Andreas Larsson
Date: Tue Feb 26 2013 - 07:17:35 EST


On 2013-02-26 11:46, Andreas Larsson wrote:
On 2013-02-26 08:52, Grant Likely wrote:
On Sat, 09 Feb 2013 14:58:55 +0000, Grant Likely
<grant.likely@xxxxxxxxxxxx> wrote:
We /could/ have a ioread32be/write32be mode in the driver, but I don't
think that is the right approach. It means we need yet another set of
accessors for register except using the 'be' variants. Blech. What I'd
actually like to do is add a bitmask field to the gpio_desc which can be
calculated ahead of time to whatever madness is required from the way
the device is wired. Then the access routines don't need to even care.
they just apply the bitmask to ioread/iowrite and it doesn't even need
to know what the bit number actually is. The new support for gpio_desc
in the core code makes this feasable.

I am not sure I understand what you mean here or what new support for
gpio_desc you are referring to (looking in gpio/next at
git://git.secretlab.ca/git/linux-2.6).

Do you mean to add something like an 'unsigned long bitmask[64]' bitmap
array with one bitmap for each gpio line to struct gpio_desc and use
this primarily by gpio-generic.c, populated in bgpio_init? Is gpio_desc
now available outside of gpiolib.c in some repository/branch that I
might be unaware of?

Ah, I realize that it is the "gpiolib: remove gpio_desc[] static array" patch series you refer to, not yet pushed to gpio/next at git://git.secretlab.ca/git/linux-2.6.

The question on how you intend the bitmap field to be defined/used/populated remains.

Cheers,
Andreas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/