Hello. On 21/12/16 19:30, Chris Healy wrote:
On Dec 21, 2016 5:11 AM, "Stefan Schmidt" <stefan@xxxxxxxxxxxxxxx <mailto:stefan@xxxxxxxxxxxxxxx>> wrote: Hello. On 19/12/16 00:25, Andrey Smirnov wrote: Driver code never touches "rstn" signal in atomic context, so there's no need to implicitly put such restriction on it by using gpio_set_value to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to fix that. We need to make sure we are not assuming it can be called in such a context in the future now. But that is something we can worry about if it comes up. As a an example of where such restriction might be inconvenient, consider a hardware design where "rstn" is connected to a pin of I2C/SPI GPIO expander chip. Is this a real life issue you run into? I have a platform with this configuration. The DTS for the platform is in the process of being mainlined right now.
Thanks for letting us know. What platform is that? I'm always interested in hearing about devices that use the Linux ieee802154 subsystem. :)
regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
