From: Marc Kleine-Budde <mkl@pengutronix.de>
To: s.grosjean@peak-system.com
Cc: Oliver Hartkopp <socketcan@hartkopp.net>,
Sebastian Haas <dev@sebastianhaas.info>,
Wolfgang Grandegger <wg@grandegger.com>,
"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: About PCAN-USB issues
Date: Tue, 31 Jan 2012 18:58:13 +0100 [thread overview]
Message-ID: <4F282BB5.40006@pengutronix.de> (raw)
In-Reply-To: <4F1EE678.2050604@peak-system.com>
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
On 01/24/2012 06:12 PM, Stephane Grosjean wrote:
> Hello all,
>
> I'm finally back to the linux-can... I'm currently working on several
> projects so the peak_usb did progress slowly these last days...
>
> Back to the issue: I changed the way the can state is handled in the
> peak_usb driver and finally get an easy tesbed to create bus-off
> events... Now, the driver puts the candev into that state only once, no
> more periodic error-warnings or else. I'm looking now to how the restart
> mechanism works.
>
> 1st: since the restart can be automatic, the related do_set_mode
> callback is called from a timer context, in which you're not allowed to
> sleep. So I suppose this is the reason of some Kernel hangs you (Oliver)
> detected last week: the peak_usb driver (tries to) reset the device by
> sending an usb message, using usb_bulk_msg(), which usage is not allowed
> in such a context! To confirm, is someone able to do the same with the
> ems_usb driver, please? It seems that this driver acts as the peak_usb
> does.
>
> Moreover, it seems that the "manual" restart is also called from such a
> timer context, so the consequences are the same...
>
> I'll have to change the way that reset is done into full asynchronous mode.
Does it make sense to replace the timer by a workqueue and schedule it
by schedule_delayed_work(). On the downside a workqueue can only be
delayed in jiffies granularity.
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: 262 bytes --]
prev parent reply other threads:[~2012-01-31 17:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1567213.2GCzMlGyKY@lisa>
2012-01-24 12:01 ` increase buffer size Oliver Hartkopp
2012-01-24 15:42 ` [Socketcan-users] " Steffen Rose
2012-01-24 16:17 ` Oliver Hartkopp
2012-01-24 17:12 ` About PCAN-USB issues Stephane Grosjean
2012-01-25 10:25 ` Wolfgang Grandegger
2012-01-31 17:58 ` Marc Kleine-Budde [this message]
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=4F282BB5.40006@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=dev@sebastianhaas.info \
--cc=linux-can@vger.kernel.org \
--cc=s.grosjean@peak-system.com \
--cc=socketcan@hartkopp.net \
--cc=wg@grandegger.com \
/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.