From: Puneet Sharma <puneet.sharma@moschip.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>,
"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: CAN device filterting
Date: Wed, 5 Sep 2012 14:58:59 +0530 [thread overview]
Message-ID: <1346837339.2993.3.camel@punsfloyd-desktop> (raw)
In-Reply-To: <504636B6.7070907@pengutronix.de>
On Tue, 2012-09-04 at 22:43 +0530, Marc Kleine-Budde wrote:
> On 09/04/2012 06:53 PM, Oliver Hartkopp wrote:
> > On 04.09.2012 15:57, Marc Kleine-Budde wrote:
> >
> >> On 09/04/2012 03:40 PM, Oliver Hartkopp wrote:
> >>> On 04.09.2012 15:31, Puneet Sharma wrote:
> >>>
> >>>> I need some guidance on implementing the CAN filtering of identifier in
> >>>> the driver code of CAN for atmel AT91SAM9263 board. Please guide me how
> >>>> to proceed with it..
> >>>
> >>>
> >>> Hm - i wrote that some days ago:
> >>
> >> I talked to Puneet in private before, if I understand him correctly he
> >> wants to implement hardware filtering, although software filtering is
> >> available.
> >
> >
> > Ah, ok.
> >
Hello,
Marc is correct. I want to implement hardware filtering. Need
some guidance on this how to proceed with it ?
> >> From my point of view it should become a per device callback, which you
> >> (admin, i.e. the root user) can set when the device is down. You have to
> >> extend the CAN netlink interface [1].
> >
> >
> > Good idea.
> >
> >> Each device should identify what kind and how many hardware filters it
> >> supports:
> >> a) mask+id
> >> b) just id
> >> c) ...
> >> Analogue to ctrlmode [2][3].
> >
> >
> > Yes. Could be ambitious. E.g. a 2048 bit bitfield is an option too :-)
> >
> > The question is, if the usual mailbox configurations in CAN controller
> > IP-cores can be stripped down to 2-3 standard types of filters, so that a good
> > interface can be specified.
>
> id+mask is quite common.
>
id+mask is what will be required for the driver.
> Marc
>
--
Puneet Sharma <puneet.sharma@moschip.com>
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
prev parent reply other threads:[~2012-09-05 9:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 13:31 CAN device filterting Puneet Sharma
2012-09-04 13:40 ` Oliver Hartkopp
2012-09-04 13:57 ` Marc Kleine-Budde
2012-09-04 16:53 ` Oliver Hartkopp
2012-09-04 17:13 ` Marc Kleine-Budde
2012-09-05 9:28 ` Puneet Sharma [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=1346837339.2993.3.camel@punsfloyd-desktop \
--to=puneet.sharma@moschip.com \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=socketcan@hartkopp.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox