我正在开发一个嵌入式Linux设备(基于NXP i.MX8迷你SoC)，它需要使用NXP的"micfil"支持麦克风音频输入"。司机(声音/soc/目前/fsl_micfil.c)。
作为初始化麦克风的一部分，我们已经添加了代码(到驱动程序的fsl_micfil_probe函数)来设置启用麦克风所需的GPIO线(通过调用devm_gpiod_get_optional)
我们当前的Linux BSP(基于Yocto的"sumo";
升级到较新的BSP时(基于Yocto的"硬节点");释放)，我们发现GPIO设置调用失败。之所以会发生这种情况，是因为在GPIO子系统可用之前调用了驱动程序的探测函数。我认为我们可以通过从其他驱动程序回调(例如在应用程序打开设备之后)进行GPIO调用来破解这个问题，但我更愿意简单地推迟这个驱动程序的探测操作，直到GPIO可用。
有办法做到这一点吗?告诉Linux这个驱动程序不应该被探测，直到GPIO启动后?或者让探针函数显式地调用GPIO启动函数?
或者有我还没有想到的更好的解决方案?
设备驱动程序的探测函数可以返回-EPROBE_DEFER(在任何必要的清理之后)，以表明它需要的资源尚未可用。然后驱动内核将该设备添加到"延迟探测"中。列出并尝试在成功探测到其他设备后调用probe函数。
请参阅文档以获取更多信息，并注意如果探针函数创建了任何子设备，则不会返回-EPROBE_DEFER的警告。
devm_gpiod_get_optional和类似的devm_gpiod_get_和gpiod_get_函数返回struct gpio_desc *值，如果请求的GPIO尚未可用，则返回ERR_PTR(-EPROBE_DEFER)。(这与未找到GPIO不同，这将导致_optional变体返回NULL，而非_optional变体返回ERR_PTR(-ENOENT)。)调用者可以将-EPROBE_DEFER错误传播给自己的调用者，但是如果创建了任何子设备，则应该再次注意关于不返回-EPROBE_DEFER的警告。