[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DC163D7.9010309@grandegger.com>
Date: Wed, 04 May 2011 16:33:59 +0200
From: Wolfgang Grandegger <wg@...ndegger.com>
To: Arnd Bergmann <arnd@...db.de>
CC: 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.
Hi Arnd,
On 05/04/2011 03:11 PM, Arnd Bergmann wrote:
> On Wednesday 04 May 2011, Subhasish Ghosh wrote:
>> CAN requires mail box IDs to be programmed in. But, the socket
>> CAN subsystem supports only software filtering of the mail box IDs.
>>
>> So, the mail box IDs programmed into socket CAN during initialization
>> does not propagate into the hardware. This is planned to be a future
>> implementation in Socket CAN.
>>
>> In our case, we support hardware filtering, to work around with this,
>> Wolfgang (Socket CAN owner) suggested that we implement
>> this using sysfs.
>>
>> These setting are not for debugging, but to program the mail box IDs
>> into the hardware.
>
> Ok, I see. Can you point me to that discussion?
>
> Wolfgang, I'm a bit worried by the API being split between sockets and sysfs.
> The problem is that once the sysfs API is established, users will start
> relying on it, and you can no longer migrate away from it, even when
> a later version of the Socket CAN also supports setting through a different
> interface. What is the current interface to set mail box IDs in software?
Note that this CAN controller is *very* special. It cannot handle all
CAN id's due to a lack or resources. The PRUSS firmware is able to
manage just up to 8 different CAN identifiers out of the usual 4096
(12-bit) or even more for the extended CAN ids using 29 bits. There is
no other CAN controller with such rather serious limitations and
therefore there exists also no appropriate interface. I think using
sysfs is OK for such device-specific parameters, at least for the time
being.
> 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.
> 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.
Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists