linux-kernel - PRUSS MFD staging driver: status update

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

Date:	Tue, 30 Jul 2013 14:17:40 -0400 (EDT)
From:	Philippe Proulx <philippe.proulx@...oirfairelinux.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Subhasish Ghosh <subhasish@...tralsolutions.com>, m-watkins@...com,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	davinci-linux-open-source@...ux.davincidsp.com,
	kernel <kernel@...oirfairelinux.com>
Subject: PRUSS MFD staging driver: status update

Hi Greg.

I am interested in continuing the work of Subhasish Ghosh regarding
TI PRUSS drivers integration on the kernel side. The last LKML reply
I'm aware of is yours, 2 years ago, here:
<https://lkml.org/lkml/2011/7/5/548>, and then there was silence.

Just a quick reminder: PRUSS (Programmable Realtime Unit SubSystem) is a
subsystem on various TI DSPs/SoCs that contains two independent RISC
cores. Each PRU has its own data/instruction RAM. See
<http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem>.

My main objective is to eventually have a soft UART (which relies on a
PRU) integrated into the mainline. Since this would depend on common
routines shared by other drivers using PRUSS (enable/disable the PRUSS
clock, load a firmware, start/stop a specific PRU, configure interrupts,
etc.), common exported PRUSS functions need to be available.

I believe that's what Subhasish Ghosh was trying to do with his PRUSS
MFD staging driver.

Now, what is the status of this? Would you still accept a valid patch
for this "MFD" driver in staging? My idea, however, is more about a set
of common functions that could be used by other "real" drivers. This
means nothing exported to user space, no sysfs, etc., since only kernel
drivers would use them (I don't intend user space drivers to rely on
this; they already have drivers/uio/uio_pruss for this).

Also, at least today, PRUSS is not only part of the DA850 devices, but
also included into OMAP-L1x8/OMAP-L1x7, C674n, AM18xx/AM17XX and
AM335x devices, so I wouldn't mention "DA8XX" in the Kconfig.

Please Cc me in any answer/comment regarding this message.

Thank you if you have any time to look into this,
Phil
--
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/