RT-Thread / RT-Thread/rt-thread
[Feature] spi deive register options hasn't incluing xxx_spi_device_attach function.Should we support it?
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 12.2k
- Forks
- 5.4k
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 40
Description
Describe problem solved by the proposed feature
这是内核中的spi_ops源码
/**
* @brief SPI operators
*/
struct rt_spi_ops
{
rt_err_t (*configure)(struct rt_spi_device *device, struct rt_spi_configuration *configuration);
rt_ssize_t (*xfer)(struct rt_spi_device *device, struct rt_spi_message *message);
};
但无论是官方的驱动书籍还是在线文档,里面都指明了最好驱动层再提供一个xxx_spi_device_attach用来绑定设备和总线。然而spi_ops并没有这样的成员。这就导致当应用层使用设备绑定时需要包含芯片厂家提供的驱动层的头文件,这不仅会膨胀代码还对头文件管理造成不便。更离谱的是有的驱动(比如stm的spi)会将xxx改成rt的形式,这很容易发生符号冲突,倘若不改成rt_spi_device_attach的形式,在应用层容易和其他组件发生混淆
Describe your preferred solution
是否考虑在内核支持(*attach)成员指针?
Describe possible alternatives
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names the rt_spi_ops definition and the xxx_spi_device_attach/rt_spi_device_attach entry points, but no source file or test is identified. Start by locating those symbols and reviewing the current SPI device-registration path; done would require an agreed kernel API design and implementation scope, which the issue does not specify.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100