All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Christian Gagneraud <chgans@gmail.com>,
	linux-can <linux-can@vger.kernel.org>
Subject: Re: New USB driver, looking for advice
Date: Tue, 8 Dec 2020 15:59:43 +0100	[thread overview]
Message-ID: <a13ab81e-ad20-0405-6935-ecd748233bc5@pengutronix.de> (raw)
In-Reply-To: <CABxGUThzGkCerMBTuA95TCs49hjHg+O-u3Z_c8=RZGJ8bVQjRQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1554 bytes --]

On 12/7/20 3:57 AM, Christian Gagneraud wrote:
> I'm looking at creating a new CAN driver for a USB device [1]. This device
> has a custom protocol over bulk endpoints. I was able to create a simple
> driver, based on usb-skeleton.c that allows to speak this protocol by opening
> a custom har device.

Do you already have code available somewhere?

> I've been looking at the current implementation in [2], I think my device is
> a bit special, you cannot read CAN frames w/o sending a 'read' command, so i
> need some sort of polling. AFAIK, the Linux USB stack provides that for me,
> except that the device won't read anything unless you send it a command.

I don't know if you have to implement the polling yourself or if there is a
polling helper. I'll ask my co-workers.

Is that a Interrupt Transfer Endpoint or a normal Bulk Endpoint?

> I have the feeling that current drivers are for devices that can
> return data by just scheduling read transfer.

Yes. Current drivers get notified by the device, if there is a CAN frame waiting.

> Anyone would have a clue on how these drivers work, and if my device
> is really that special?

Yes, your device is quite special :)

> Any hint, point out or reading pointers are much appreciated.

Marc

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


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

  reply	other threads:[~2020-12-08 15:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-07  2:57 New USB driver, looking for advice Christian Gagneraud
2020-12-08 14:59 ` Marc Kleine-Budde [this message]
2020-12-09 11:03   ` Marc Kleine-Budde
2020-12-09 20:24   ` Christian Gagneraud
2020-12-10  7:36     ` Marc Kleine-Budde
2020-12-10 22:26       ` Christian Gagneraud
2020-12-11  8:39         ` Marc Kleine-Budde
2021-02-18  2:14           ` Christian Gagneraud

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=a13ab81e-ad20-0405-6935-ecd748233bc5@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=chgans@gmail.com \
    --cc=linux-can@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.