linux-kernel - RE: [PATCH v2 02/13] da850: pruss platform specific additions.

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] [day] [month] [year] [list]

Date:	Thu, 3 Mar 2011 16:42:58 +0530
From:	"TK, Pratheesh Gangadhar" <pratheesh@...com>
To:	Subhasish Ghosh <subhasish@...tralsolutions.com>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>
CC:	"sachi@...tralsolutions.com" <sachi@...tralsolutions.com>,
	Russell King <linux@....linux.org.uk>,
	Kevin Hilman <khilman@...prootsystems.com>,
	open list <linux-kernel@...r.kernel.org>,
	"Watkins, Melissa" <m-watkins@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v2 02/13] da850: pruss platform specific additions.

Hi,

> -----Original Message-----
> From: Subhasish Ghosh [mailto:subhasish@...tralsolutions.com]
> Sent: Tuesday, March 01, 2011 12:29 PM
> Hello,
> 
> Can we not have the PRU UIO also as a part of the MFD framework.
> I know that the UIO is not really a device, but I feel its incorrect to
> register the same device twice.
> Instead we can have a single entry as the MFD framework and the UIO, as a
> child device, based upon the MFD driver APIs.
> 
> All that we need to do is add an entry into the da8xx_pruss_devices
> structure
> and the MFD driver will do the rest to get the UIO probe called.
> 
Well I see the need for MFD for in-kernel PRUSS based drivers like UART/CAN, 
but UIO use cases are typically mutually exclusive to this. UIO driver 
exports whole PRUSS I/O region and Interrupts to user space application and 
all the tasks including PRUSS INTC setup, loading firmware and
enable/disable PRUs are handled by PRUSS user driver.
I feel it will be a nightmare to make them co-exist unless say we have
2 instances of PRUSS in a SOC. Think about kernel driver setting up PRUSS, PINTC and loading firmware and user land overriding and vice versa. Things are much simpler if we make the usage model mutually exclusive.
Also I don't see any overlap in functionality and reuse UIO can gain from
MFD driver.  
Since we can't register device twice - I would prefer KConfig based check
for the same. 

Also can you point me where you add UART and CAN driver as children to PRUSS
MFD driver - I can't seem to find this in patches.

Thanks,
Pratheesh
--
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/