On Wed, Apr 22, 2015 at 06:29:33PM +0200, Johan Hovold wrote: > On Tue, Mar 17, 2015 at 02:59:08AM +0000, Frkuska, Joshua wrote: > > Hello, > > > > In 3.18, the upstream commit e1db1706c8 made it acceptable to remove > > gpio chips that were in use in exchange for a critical message. The > > reasoning from what I gathered from the mailing list was to avoid > > handling errors in the device remove handler. The justification was > > that the error seemed unused by most drivers and there was a compiler > > warning when ignoring the return value. > > > > At a higher level, this is a gpio handling policy shift. Previously > > the behavior was to result in an error and disallow the gpio device to > > be removed. Then starting at 3.18, it becomes ok to free a gpio device > > regardless of whatever the (possibly critical) gpio may be doing as > > long as a critical message is displayed. > > It still isn't acceptable to remove a gpio chip with requested gpios as > it will lead to memory leaks (even though the most pre-3.18 crashes have > been fixed). To clarify: the memory leaks are primarily related to sysfs. The major issue is of course the crashes when attempting to call into chip drivers whose device state is likely deallocated with descriptors and chip structures that also have or could have been freed (e.g. as in your i2c example). This only affects in-kernel consumers using the gpiod-interface. So to summarise: Using a requested gpio post chip-removal is not supported. Johan -- 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