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]
Message-ID: <108709052.651756.1375208260748.JavaMail.root@mail>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ