> > > struct gpio_desc { > > > struct gpio_chip *chip; > > > unsigned is_out:1; > > > + unsigned requested:1; > > > +#ifdef CONFIG_DEBUG_FS > > > + const char *requested_str; > > > +#endif > > > > Note that this means (on typical 32-bit embedded hardware) > > twelve bytes per GPIO, which if you assume 256 GPIOs means > > an extra 3 KB static memory compared to the patch I sent.
Actually, 2K is a more accurate number -- ignore DEBUG_FS. > Note this reduces the memory in gpio_chip, so it consumes almost same > memory as the patch you sent. No; the amount of space shaved from a typical (32-bit banks) gpio_chip is *exactly* the cost of one gpio_desc: two words. In one case, two bitmaps. In the other, a pointer, two bits, and internal struct padding. So unless each bank has only a single GPIO, this approach does cost more memory. Both for the extra memory associated with each gpio_chip that's used, and for unused gpio_desc. That's not necessarily a bad thing, though it's always worth avoiding bloat. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/