Re: usb-can device

[Marc Kleine-Budde <mkl@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]

Hello,

Max, please leave the mailinglist on Cc.

On 08/28/2012 01:58 PM, Oliver Hartkopp wrote:
> On 27.08.2012 14:40, Max S. wrote:
> 
>> On Mon, 2012-08-27 at 08:20 +0200, Oliver Hartkopp wrote:
> 
>>> The idea is to bring the USB CAN interface as near as possible to the
>>> SocketCAN network interface:
>>
>> Exactly. The device should know what a struct can_frame is. The device i
>> have is more than powerful enough to do some extra converting, endian
>> etc (its an atmel devboard).
>> I have been reading the Peak CAN-USB driver source, they seem to do the
>> conversion on the host with a simple
>> #ifdef ENDIAN be or le ... 
>>
>> compiling either the big endian or the little endian code.
>>
>> but a single memcpy would be allot cleaner.
> 
> 
> Yes. In general the content from the CAN registers needs to be copied into the
> URB from the CAN USB CPU anyway. So the idea is to do it in host-byteorder.
> This has a very small impact to the CAN CPU complexity and makes it really
> easy on the host driver side.
> 
>>> - send struct can_frames
>>> - receive struct can_frames (for instant CAN data forwarding)
>>> - receive struct can_frames (for instant CAN error messages(!) forwarding)
>>> - send an endian pattern inside the USB URB (*1)
>>> - send skb->sk pointers along with CAN data (*2)
>>> - define a simple interface for open/close/bitrate-setting
>>>
>>> *1:
>>> The idea is to reduce the CAN network driver to make simple memcpy()
>>> operations instead of do any bitshifting or endian conversions. For that
>>> reason an endian pattern (e.g. 0xAA00AA00) is added to the USB URB at
>>> send/configuration, so that the CAN USB adapter switches to the host endian
>>> mode and replies with the same endian pattern before the CAN data.
>>> This allows to simply memcpy() the received CAN frame into skb->data.
>>>
>>> *2:
>>> To provide a state-of-the-art echo functionality the sk pointer (skb->sk) is
>>> sent along with the CAN frame. This allows to skb_free() the original tx skb
>>> and create a new one at rx time with the correct sk pointer, when the frame is
>>> echoed after successful transmission. As we are endian safe the sk pointer can
>>> be taken from the USB URB as-is. (For security reasons we should probably not
>>> take the pointer directly but double check with stored echo-skbs)
>>
>> hm. I also don't think it would be wise to accept a pointer from the
>> outside in kernel space. maybe accept an index(that can be checked) into
>> a pointer array?.. I don't know, I'm not at that point yet :P.
>>
> 
> 
> I found a very interesting implementation in the Bosch M_CAN specification:
> 
> http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/m_can/m_can.asp
> 
> http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/m_can/mcan_users_manual.pdf
> 
> Section 2.4.3 Tx Buffer Element (page 45)
> 
> ---8<---
> 
> T1 Bits 31:24 MM[7:0]: Message Marker
> 
> Written by CPU during Tx Buffer configuration. Copied into Tx Event FIFO
> element for identification of Tx message status.
> 
> ---8<---
> 
> So you can see in the Tx event FIFO, which marked CAN frame has been sent.
> 
> This is probably enough to provide just a byte and to create an array of
> skb pointers which is referenced by this Message Marker. Maybe 256 markers
> are too much ... we could only use 8 markers IMO.

Why not a full u32? Then you're free on the driver side to do what you
want with it.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]