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: <201103041658.05655.arnd@arndb.de>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ