linux-kernel - Re: [PATCH v4 1/1] can: add pruss CAN driver.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201105112331.47954.arnd@arndb.de>
Date:	Wed, 11 May 2011 23:31:47 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Subhasish Ghosh" <subhasish@...tralsolutions.com>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Wolfgang Grandegger" <wg@...ndegger.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.

On Tuesday 10 May 2011, Subhasish Ghosh wrote:
> 
> >> Yes, In case if we allow the ALL implementation, it hogs the CPU.
> >> In that case we do not need the PRU. The whole purpose of the PRU
> >> is to offload the processor for any such implementations. 
> > 
> > So the kernel presumably needs to switch between using the PRU and native
> > according to the number of ids being requested at the time ?
> 
> All the IDs are programmed into the PRU data RAM.
> The Kernel receives interrupts based upon these IDs.
> I could not clearly follow "PRU and native", could you please elaborate.

We would really like all CAN drivers to behave the same way. All other
drivers are able to work without filters, so pruss_can should allow that
too, even if it becomes a CPU hog at that time.

It seems to me that the pruss can implementation has one thing backwards:
it assumes a specific usage model for CAN that it is trying to do offload
for. However, that usage model is currently not even supported by Socket
CAN. If I understand Wolfgang correctly, it is in fact considered an
unwanted limitation of the pruss can driver, instead of a useful feature.

If that interpretation is right, I would seriously recommend rethinking
the design of the CAN firmware for pruss, so you can start doing something
useful with the offload engine that fits into the Socket CAN API, or that
would be a useful extension to Socket CAN that is also implementable in
the kernel for all other drivers in a meaningful way.

	Arnd
--
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/