On Mon, Mar 19, 2018 at 9:00 AM, Lukas Wunner <lukas@xxxxxxxxx> wrote: > On Sun, Mar 18, 2018 at 09:34:12PM +0100, Rasmus Villemoes wrote: >> On 2018-03-18 15:23, Lukas Wunner wrote: >> > Actually, scratch that. If ngpio is usually smallish, we can just >> > allocate reasonably sized space for mask and bits on the stack, >> > and fall back to the kcalloc slowpath only if chip->ngpio exceeds >> > that limit. >> Well, I'd suggest not adding that fallback code now, but simply add a >> check in gpiochip_add_data_with_key to ensure ngpio is sane (and refuse >> to register the chip otherwise), at least if we know that every >> currently supported/known chip is covered by the 256 (?). > > The number 256 was arbitrarily chosen. I really wouldn't be surprised > if gpiochips with more pins exist, but they're probably rare, so using > the slowpath seems fine, but dropping support for them completely would > be a regression. All modern Intel SoCs have GPIO count in between of ~230-380. Though, few of them are split to communities by (much) less than 256 pin in each when there is a 1:1 mapping between community and gpiochip. OTOH, the function you are fixing is most likely is not used together with the drivers for x86. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html