From: Marc Kleine-Budde <mkl@pengutronix.de>
To: "Max S." <max@schneidersoft.net>
Cc: linux-can <linux-can@vger.kernel.org>
Subject: Re: Usb to can driver
Date: Wed, 24 Apr 2013 18:07:18 +0200 [thread overview]
Message-ID: <51780336.5060800@pengutronix.de> (raw)
In-Reply-To: <1366818490.5965.35.camel@blackbox>
[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]
On 04/24/2013 05:48 PM, Max S. wrote:
>> Please use "./scripts/checkpatch.pl" from the kernel and fix all
>> coding style errors. Then repost :).
Please check your patch with ./scripts/checkpatch.pl, fix the errors,
then repost.
>> Can you explain how the "struct device_config" works.
>>
> struct __packed device_config {
> u16 byte_order;
>
> u32 hf_size; /* size of a host frame */
> u32 hf_can_id;
> u32 hf_can_dlc;
> u32 hf_data;
> u32 hf_echo_id;
> u32 hf_channel;
> } conf;
>
> conf = (struct device_config){
> .byte_order = 0xbeef,
> .hf_size = sizeof(struct ss_host_frame),
> .hf_can_id = offsetof(struct ss_host_frame, frame.can_id),
> .hf_can_dlc = offsetof(struct ss_host_frame, frame.can_dlc),
> .hf_data = offsetof(struct ss_host_frame, frame.data),
> .hf_echo_id = offsetof(struct ss_host_frame, echo_id),
> .hf_channel = offsetof(struct ss_host_frame, channel),
> };
>
> ... send conf to device, packed that should be 26 bytes.
>
> The device uses byte_order which will appear as either 0xbeef or 0xefbe
> to convert the other members to device byte order. (and to convert all
> future messages)
Use a u32 here instead of an u16, this way the struct is properly aligned.
> The device can then tell how the host prefers its can frames formatted.
> The idea is that the struct device_config holds enough data to allow the
> device to construct a struct ss_host_frame in host format, including
> padding & byte order.
Nice.
> since a struct ss_host_frame is simply a wrapper that includes a struct
> can_frame, when a message arrives from the device, the host can copy the
> struct can frame member without modification from the struct
> ss_host_frame into the skb.
>
> assumptions that are made:
> * The sizes of the struct can_frame members are id:u32 dlc:u8 data:u64 .
> * It is also assumed that existing defines like CAN_EFF_FLAG in can.h
> and can/error.h don't change, as they are used by the device to
> construct the can_id field.
You cannot rely in your firmware, that the struct can_frame and
CAN_*_FLAG doesn't change. Please define your own struct.
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: 263 bytes --]
next prev parent reply other threads:[~2013-04-24 16:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 17:15 Usb to can driver Max S.
2013-04-23 21:47 ` Marc Kleine-Budde
2013-04-24 15:48 ` Max S.
2013-04-24 16:07 ` Marc Kleine-Budde [this message]
2013-04-24 17:40 ` Oliver Hartkopp
2013-04-24 21:24 ` Marc Kleine-Budde
2013-04-25 23:35 ` Max S.
2013-04-26 5:25 ` Oliver Hartkopp
2013-04-26 8:55 ` Kurt Van Dijck
2013-04-26 8:26 ` Marc Kleine-Budde
2013-04-24 21:33 ` Max S.
2013-05-02 11:07 ` Marc Kleine-Budde
2013-05-02 11:09 ` Marc Kleine-Budde
2013-05-02 11:30 ` Wolfgang Grandegger
2013-05-02 11:32 ` Marc Kleine-Budde
2013-05-16 11:40 ` Marc Kleine-Budde
2013-06-04 13:18 ` Max S.
2013-06-04 14:40 ` Wolfgang Grandegger
2013-06-04 14:41 ` Marc Kleine-Budde
2013-04-24 6:38 ` Sven Geggus
-- strict thread matches above, loose matches on Subject: below --
2013-06-25 23:59 Max S.
2013-06-26 7:10 ` wg
2013-06-26 18:55 ` Max S.
2013-06-26 18:58 ` Marc Kleine-Budde
[not found] ` <1372810462.15632.2.camel@blackbox>
2013-07-03 7:55 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51780336.5060800@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=max@schneidersoft.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).