From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22774 invoked by alias); 15 Jan 2012 13:56:34 -0000 Received: (qmail 22754 invoked by uid 22791); 15 Jan 2012 13:56:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Jan 2012 13:56:19 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id C88E72F78010 for ; Sun, 15 Jan 2012 13:56:17 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybplfBCPlcr7; Sun, 15 Jan 2012 13:56:16 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001453] CAN IO package: wider flags field, flag to report return to 'error active' mode X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sergei.gavrikov@gmail.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Sun, 15 Jan 2012 13:56:00 -0000 Message-Id: <20120115135616.061B92F78006@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00056.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001453 --- Comment #4 from Sergei Gavrikov 2012-01-15 13:56:08 GMT --- (In reply to comment #3) > I also forgot to document the meaning of the added flag ;-) Of course, we need to keep in sync documentation and sources. > 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 > capabilities. > > The 'SW-Filt' flag has been replaced by 'autobaud' in the source code > (my patch fixes the doc about this). I've seen. Thank you for the catch. > 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. It seems so. > 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) Agreed. > The side effect is a need for more config keys, to declare filtering > information. IMO, it is not issue for eCos, more that default values would not break old flag's value. > 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. Excellent coincidence. > 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. Great. > 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'. Bernard, thank you for your investigation. I think the patches can be submitted here to save full history of issue, but, if you prefer a separate Bugzilla report, please, create new one. One thing then. Now, all your enhancements need to get a copyright assignment from you as I see your "delta" won't be a-few-lines trivial patch. Could you, please, initiate a copyright assignments process? You can find more info here: http://ecos.sourceware.org/assign.html -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.