GPIO驱动框架疑惑 一个接口设计的细节疑惑

1. 保持兼容
2. 留着备用

传递句柄是很常见的用法，即使当前项目不用，下面是个别的程序，原理一样。

static rt_err_t mic_configure(struct rt_audio_device *audio, struct rt_audio_caps *caps)
{
    rt_err_t result = RT_EOK;
    struct mic_device *mic_dev;
    RT_ASSERT(audio != RT_NULL);
    mic_dev = (struct mic_device *)audio->parent.user_data;

[i=s] 本帖最后由 大话西游2018 于 2019-11-12 11:03 编辑 [/i]

1. 保持兼容
2. 留着备用

对于您说的保持兼容，我理解为: RT Thread先写了驱动框架层，所以导致后面的stm32的底层驱动层的函数参数多出了这第一个参数，实际用不到。
对于您说的留着备用，怎么理解？stm32或者其他芯片，有需要用到这第一个参数的场景吗？

我疑惑，哪里会使用到上图的父类方法呢(本论坛图3)？哪里会切切实实用到了_hw_pin.parent提供的成员？

stm32不用，用不到，没有用。

明天也许stm33也会用，请不要纠结。

[attach]12216[/attach]
[attach]12217[/attach]

这两处有用到parent方法，慢慢看吧

[i=s] 本帖最后由 大话西游2018 于 2019-11-12 11:41 编辑 [/i]

stm32不用，用不到，没有用。

明天也许stm33也会用，请不要纠结。

[attach]12218[/attach]
A处使用，例如can的接收回调。 B的使用处就更多了，例如stm32 bsp GPIO那块。 那么C呢，在哪用到了？ 区分B和C有什么意义吗？？

https://www.rt-thread.org/qa/thread-422568-1-1.html

devfs可以用，也许现在还不能，有需要就去改好。

换个说法，如果不打算用devfs，这里全空着，也没什么关系吧。
总感觉楼主想把这个结构体里面这几个成员给删除了。
这里可以删，其它设备呢？

[i=s] 本帖最后由 大话西游2018 于 2019-11-12 11:56 编辑 [/i]

https://www.rt-thread.org/qa/thread-422568-1-1.html

devfs可以用，也许现在还不能，有需要就去改好。

我两篇帖子最终都逃不过parent方法的意义。(6楼 图片)

parent非常重要，扮演了中间层的角色。 具体某个设备的抽象层《==》Parent通用设备抽象层《==》内核对象Object层。

这样理解更合适吧