From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public•gmane.org>
To: christian pellegrin <chripell-VaTbYqLCNhc@public•gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public•gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org
Subject: Re: [PATCH net-next-2.6 v2] can: mcp251x: Move to threaded interrupts instead of workqueues.
Date: Wed, 03 Feb 2010 08:49:33 +0100 [thread overview]
Message-ID: <4B692A8D.2040000@grandegger.com> (raw)
In-Reply-To: <cabda6421002022323m6ea676afu6c73843280b75e24-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
christian pellegrin wrote:
> On Tue, Feb 2, 2010 at 11:00 AM, Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public•gmane.org> wrote:
>> Hi Christian,
>>
>
> Hi,
>
>> The MERR should not come when the device is in bus-off. Nevertheless, it
>
> yes, sorry it's in error-passive state!
Yep. That's where it sits if you send a message with no cable connected
or no other node on the bus.
>> space via error messages. For exactly that reason we do not disable bus
>> errors on other CAN controllers, like the SJA1000 or the AT91, even if
>> they may produce high load. But we may discuss some generic interface to
>> disable bus-errors somehow, maybe configurable via ctrlmode. What do you
>> think?
>
> The transition of CAN error states is handled by the ERR interrupt,
> the MERR means "message error" and is fired when a transmission or
> receptions leads to an error. The problems with this interrupt are:
>
> 1) it's impossible to know if it was a TX or RX error.
>
> 2) if the error is accounted (for example) to TX the user will see
> ton's of TX errors even if he sent just one packet (this happens in
> error-passive mode for example) which could be confusing.
It's the same on the SJA1000, our reference controller.
> 3) I guess that microchip has a specific use of this interrupt in mind
> which explains it's drawbacks. From the data sheet:
>
> "7.4 Message Error Interrupt
> When an error occurs during transmission or reception
> of a message the message error flag (CAN-
> INTF.MERRF) will be set and, if the CANINTE.MERRE
> bit is set, an interrupt will be generated on the INT pin.
> This is intended to be used to facilitate baud rate deter-
> mination when used in conjunction with listen-only
> mode."
OK. If the bus-error does not provide additional information, like ack,
form, stuff, bit, etc. error, it's maybe not worth to support it.
Therefore, not enabling MERR is fine for the moment.
> I think that a much more useful information to somehow export to the
> user are the TEC and REC counters. I checked other CAN drivers but no
> one seems to do this. Anyway let me know what do you think so I could
> prepere the final patch now that OSM problems where sorted out.
CAN experts told me/us, that the bus-errors might be important
information for an apps. I just started a thread on how to improve our
current bus-error handling implementation.
Wolfgang.
next prev parent reply other threads:[~2010-02-03 7:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-30 13:19 [PATCH net-next-2.6] can: mcp251x: Move to threaded interrupts instead of workqueues Christian Pellegrin
[not found] ` <1264857564-3917-1-git-send-email-chripell-VaTbYqLCNhc@public.gmane.org>
2010-01-30 19:49 ` Wolfgang Grandegger
[not found] ` <4B648D3F.30909-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2010-01-31 17:39 ` christian pellegrin
[not found] ` <cabda6421001310939g4acd22d2ua8dab4de3322f90e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-31 17:43 ` [PATCH net-next-2.6 v2] " Christian Pellegrin
[not found] ` <1264959793-1797-1-git-send-email-chripell-VaTbYqLCNhc@public.gmane.org>
2010-02-01 7:10 ` christian pellegrin
2010-02-02 10:00 ` Wolfgang Grandegger
2010-02-03 7:23 ` christian pellegrin
[not found] ` <cabda6421002022323m6ea676afu6c73843280b75e24-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-02-03 7:49 ` Wolfgang Grandegger [this message]
[not found] ` <4B692A8D.2040000-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2010-02-03 17:39 ` christian pellegrin
[not found] ` <cabda6421002030939w3788a40en38955d31dd765583-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-02-03 17:39 ` [PATCH net-next-2.6 v3] " Christian Pellegrin
[not found] ` <1265218794-25808-1-git-send-email-chripell-VaTbYqLCNhc@public.gmane.org>
2010-02-03 20:14 ` Wolfgang Grandegger
2010-02-04 4:33 ` David Miller
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=4B692A8D.2040000@grandegger.com \
--to=wg-5yr1bzd7o62+xt7jha+gda@public$(echo .)gmane.org \
--cc=chripell-VaTbYqLCNhc@public$(echo .)gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public$(echo .)gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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