linux-kernel - Re: [PATCH v10 1/1] PRUSS UIO driver support

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]

Date:	Fri, 4 Mar 2011 16:58:05 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Nori, Sekhar" <nsekhar@...com>
Cc:	"Hans J. Koch" <hjk@...sjkoch.de>,
	"TK, Pratheesh Gangadhar" <pratheesh@...com>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"sshtylyov@...sta.com" <sshtylyov@...sta.com>,
	"Chatterjee, Amit" <amit.chatterjee@...com>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v10 1/1] PRUSS UIO driver support

On Friday 04 March 2011, Nori, Sekhar wrote:
> On Fri, Mar 04, 2011 at 19:50:28, Hans J. Koch wrote:
> > On Fri, Mar 04, 2011 at 10:12:52AM +0530, Pratheesh Gangadhar wrote:
> > > diff --git a/include/linux/uio_pruss.h b/include/linux/uio_pruss.h
> > > new file mode 100644
> > > index 0000000..8c9b2c9
> > > --- /dev/null
> > > +++ b/include/linux/uio_pruss.h
> > 
> > That should go to arch/arm/mach-davinci/include/mach/
> > and not to the top level include/linux/ directory.
> 
> It was put in here because this driver
> will be used across two ARM architectures
> (DaVinci and OMAP). Although it won't be used
> outside of ARM at least in near future.

I think include/linux/ is fine for this, and arch/arm/include/asm would
be ok as well. You might want to have only a single pruss header
file that defines all the platform data for the child drivers, though.

Ideally, you would of course not need the header at all. This will
be possible with the move to a flat device tree, where you can store the
offset as a property of the device

Another alternative would be to move it to a resource of the platform
device.

	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/