[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110504155750.GC322@e-circ.dyndns.org>
Date: Wed, 4 May 2011 17:57:50 +0200
From: Kurt Van Dijck <kurt.van.dijck@....be>
To: Wolfgang Grandegger <wg@...ndegger.com>
Cc: Arnd Bergmann <arnd@...db.de>,
Subhasish Ghosh <subhasish@...tralsolutions.com>,
linux-arm-kernel@...ts.infradead.org,
Marc Kleine-Budde <mkl@...gutronix.de>,
sachi@...tralsolutions.com,
davinci-linux-open-source@...ux.davincidsp.com,
Netdev@...r.kernel.org, nsekhar@...com,
open list <linux-kernel@...r.kernel.org>,
CAN NETWORK DRIVERS <socketcan-core@...ts.berlios.de>,
m-watkins@...com
Subject: Re: [PATCH v4 1/1] can: add pruss CAN driver.
>
> > How hard would it be to implement that feature in Socket CAN?
>
> CAN controllers usually provide some kind of hardware CAN id filtering,
> but in a very hardware dependent way. A generic interface may be able to
> handle the PRUSS restrictions as well. CAN devices are usually
> configured through the netlink interface. e.g.
>
> $ ip link set can0 up type can bitrate 125000
>
> and such a common interface would be netlink based as well.
ack.
>
> > Is that something that Subhasish or someone else could to as a prerequisite
> > to merging the driver?
>
> Any ideas on how to handle hardware filtering in a generic way are
> welcome. I will try to come up with a proposal sooner than later.
When doing so, I'd vote for an unlimited(by software) list of hardware filters (id/mask).
The hardware must abort when no more filters are available.
I think that when using hardware filters, knowing the actual device
with it's amount of hardware filters is the least of your problems.
Userspace applications that suddenly stop working properly due to
hw filters (i.e. some traffic not coming in anymore) will be a major
source of bugreports.
Kurt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists