how CAN-bus Linux driver MCP251x.c works
I am studying CAN-bus chip Linux driver, MCP251x.c in the kernel source. However, I find a little confused about how this driver works, it registers itself as a SPI slave device using the structure struct spi_driver mcp2510_can_driver = { .driver = {...} .probe= ... } In probe function, it registers itself as a "net_device" with "mcp251x_netdev_ops". So I am not sure how this system works. I know that the userspace must see it as a network driver. But can userspace really see this driver? Or what it can see is the module "can.ko" -- the protocol stack ? Does the network stack talks to SPI and SPI talks to mcp2510 chip and transmit messages can-bus? Or something else? Thanks -- Cheng(誠) My Page: http://freakrobot.blogbus.com/
Hi Cheng, On Fri, Jan 14, 2011 at 6:23 AM, cheng chen <freakrobot@acm.org> wrote:
I am studying CAN-bus chip Linux driver, MCP251x.c in the kernel source. However, I find a little confused about how this driver works, it registers itself as a SPI slave device using the structure struct spi_driver mcp2510_can_driver = { .driver = {...} .probe= ... } In probe function, it registers itself as a "net_device" with "mcp251x_netdev_ops". So I am not sure how this system works. I know that the userspace must see it as a network driver. But can userspace really see this driver? Or what it can see is the module "can.ko" -- the protocol stack ? Does the network stack talks to SPI and SPI talks to mcp2510 chip and transmit messages can-bus? Or something else?
I haven't looked at the code but I have looked at the chip, and I've been sort of following along on the Socket-CAN list. https://lists.berlios.de/mailman/listinfo/socketcan-users It would register itself with the network stack, and the network stack will expect to send and receive packets. The CAN driver then needs to send these packets to the chip over a SPI bus. So it uses the SPI infrastructure to send these packets to the actual MCP2510. Every system has different SPI devices, so this way, the MCP2510 driver doesn't have to know how the actual SPI layer works, it just knows it needs to use the SPI protocol to talk to the MCP2510.
From userspace, you would use the socket API to send you data to whatever device you're communicating with via CAN.
So the whole thing should go together something like this: user space talks to socket API network driver talks to CAN driver CAN driver talks to SPI driver SPI driver talks to SPI hardware messages go over the SPI bus to MCP2510 MCP2510 sends messages over the CAN bus to the actual device Dave Hylands
On Fri, Jan 14, 2011 at 11:28 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Cheng,
On Fri, Jan 14, 2011 at 6:23 AM, cheng chen <freakrobot@acm.org> wrote:
I am studying CAN-bus chip Linux driver, MCP251x.c in the kernel source. However, I find a little confused about how this driver works, it registers itself as a SPI slave device using the structure struct spi_driver mcp2510_can_driver = { .driver = {...} .probe= ... } In probe function, it registers itself as a "net_device" with "mcp251x_netdev_ops". So I am not sure how this system works. I know that the userspace must see it as a network driver. But can userspace really see this driver? Or what it can see is the module "can.ko" -- the protocol stack ? Does the network stack talks to SPI and SPI talks to mcp2510 chip and transmit messages can-bus? Or something else?
I haven't looked at the code but I have looked at the chip, and I've been sort of following along on the Socket-CAN list. https://lists.berlios.de/mailman/listinfo/socketcan-users
It would register itself with the network stack, and the network stack will expect to send and receive packets. The CAN driver then needs to send these packets to the chip over a SPI bus. So it uses the SPI infrastructure to send these packets to the actual MCP2510.
Every system has different SPI devices, so this way, the MCP2510 driver doesn't have to know how the actual SPI layer works, it just knows it needs to use the SPI protocol to talk to the MCP2510.
From userspace, you would use the socket API to send you data to whatever device you're communicating with via CAN.
So the whole thing should go together something like this:
user space talks to socket API network driver talks to CAN driver CAN driver talks to SPI driver SPI driver talks to SPI hardware messages go over the SPI bus to MCP2510 MCP2510 sends messages over the CAN bus to the actual device
Dave Hylands
Thanks for your help, I understand the frameworks now. But if I want to make the CAN driver(mcp251x.c) works on my own embedded board, should do some work to make the SPI fit my hardware? -- Cheng(誠) Fedora Project Contributor -- Ambassador https://fedoraproject.org/wiki/User:Freakrobot _______________________________________________ My Page: http://freakrobot.blogbus.com/
Hi Cheng, On Fri, Jan 14, 2011 at 8:31 AM, cheng chen <freakrobot@acm.org> wrote: ...snip...
Thanks for your help, I understand the frameworks now. But if I want to make the CAN driver(mcp251x.c) works on my own embedded board, should do some work to make the SPI fit my hardware?
You would need to implement the SPI driver using the SPI infrastructure so that the CAN driver can use it. See Documentation/spi directory for documentation on the SPI infrastructure. Dave Hylands
Thanks very much. On Sat, Jan 15, 2011 at 3:26 AM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Cheng,
On Fri, Jan 14, 2011 at 8:31 AM, cheng chen <freakrobot@acm.org> wrote: ...snip...
Thanks for your help, I understand the frameworks now. But if I want to make the CAN driver(mcp251x.c) works on my own embedded board, should do some work to make the SPI fit my hardware?
You would need to implement the SPI driver using the SPI infrastructure so that the CAN driver can use it.
See Documentation/spi directory for documentation on the SPI infrastructure.
Dave Hylands
-- Cheng(誠) Fedora Project Contributor -- Ambassador https://fedoraproject.org/wiki/User:Freakrobot _______________________________________________ My Page: http://freakrobot.blogbus.com/
participants (2)
-
cheng chen -
Dave Hylands