public inbox for
 help / color / mirror / Atom feed
Subject: [Bug 1001453] CAN IO package: wider flags field, flag to report return to 'error active' mode
Date: Sat, 14 Jan 2012 22:40:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Please do not reply to this email. Use the web interface provided at:

--- Comment #3 from Bernard Fouché <> 2012-01-14 22:39:39 GMT ---
I also forgot to document the meaning of the added flag ;-)

While thinking at other things I may have forgotten, I now see an issue with
the bitfield 'support_flags' in cyg_can_hdi.

Here is cyg_can_hdi:

typedef struct cyg_can_hdi_st
    cyg_uint8 support_flags;
    cyg_uint8 controller_type;
} cyg_can_hdi;

The issue is a lack of description of the low level driver filtering

The 'SW-Filt' flag has been replaced by 'autobaud' in the source code (my patch
fixes the doc about this).

Hence there is no more description of a hw driver filtering capabilities while
these capabilities are essential in a real world CAN network. The 'software
filtering' information was not very helpful to user code anyway, I suppose
that's why it has been removed and the corresponding bit recycled.

I suggest to use two reserved bits in 'support_flags':

- a bit to describe identifier range filtering capability (0=no range
filtering, this keep compatibility with current code)

- a bit to describe bitmask filtering capability (0=no bitmask filtering). I
think bitmask filtering is the most common and efficient way to filter CAN
frames. (While LPC17XX has range filtering capabilities, the upcoming LPC18XX
has bitmask filtering instead)

The side effect is a need for more config keys, to declare filtering

The LPC2XXX driver provides identifier range filtering config keys (as a cdl
option), but since the CAN IO package does not support range filtering (in
terms of API convention), these supplementary config keys can be obtained by
user code only by including explicitly the LPC2XXX specific header file.

If these two new data bits in 'support_flags' are added, then the config keys
provided by the LPC2XXX driver can become the 'official' config keys for
identifier range filtering.

And of course there is also a need for config keys related to bitmask
filtering. AFAIK, bitmask filtering is made by declaring an identifier value
and a bitmask, so the config keys related to bitmask filtering would need 2 x
32 bits value for config data (like the LPC2XXX range filtering key)

Since the CAN IO package relay to the hardware layer the config keys it does
not handle itself, there would be no functional change in the package, like the
patch I proposed.

If this is ok I'll provide an updated patch (using the diff option you
mention), and combine these changes. 

Or I can provide two patches, one to fix the patch I proposed, and then I open
a new bugzilla entry with a new patch related to 'support_flags'.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

  parent reply	other threads:[~2012-01-14 22:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13 16:16 [Bug 1001453] New: " bugzilla-daemon
2012-01-13 16:17 ` [Bug 1001453] " bugzilla-daemon
2012-01-14 18:51 ` bugzilla-daemon
2012-01-14 22:40 ` bugzilla-daemon [this message]
2012-01-15 13:56 ` bugzilla-daemon
2012-01-15 22:30 ` bugzilla-daemon
2012-01-16  8:16 ` bugzilla-daemon
2012-01-18 21:48 ` bugzilla-daemon
2012-01-19 20:46 ` bugzilla-daemon
2012-01-24 19:25 ` bugzilla-daemon
2012-01-25 11:35 ` bugzilla-daemon
2012-01-25 11:39 ` bugzilla-daemon
2012-01-25 11:44 ` bugzilla-daemon
2012-01-25 11:45 ` bugzilla-daemon
2012-01-25 13:59 ` bugzilla-daemon
2012-01-25 20:07 ` bugzilla-daemon
2012-01-26  8:51 ` bugzilla-daemon
2012-02-06 10:00 ` bugzilla-daemon
2012-02-06 15:57 ` bugzilla-daemon
2012-02-06 20:30 ` bugzilla-daemon
2012-02-07  6:13 ` bugzilla-daemon
2012-02-09 21:46 ` bugzilla-daemon
2012-02-10 17:28 ` bugzilla-daemon
2012-02-11  4:16 ` bugzilla-daemon

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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 read-only IMAP folder(s) and NNTP newsgroup(s).