linux-kernel - Re: [PATCH v4 01/11] mfd: add pruss mfd driver

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: <20110524134338.GA13491@kroah.com>
Date:	Tue, 24 May 2011 06:43:38 -0700
From:	Greg KH <greg@...ah.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Subhasish Ghosh <subhasish@...tralsolutions.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	"Nori, Sekhar" <nsekhar@...com>,
	linux-arm-kernel@...ts.infradead.org,
	davinci-linux-open-source@...ux.davincidsp.com,
	sachi@...tralsolutions.com, Samuel Ortiz <sameo@...ux.intel.com>,
	open list <linux-kernel@...r.kernel.org>,
	"Watkins, Melissa" <m-watkins@...com>
Subject: Re: [PATCH v4 01/11] mfd: add pruss mfd driver

On Tue, May 24, 2011 at 02:40:34PM +0200, Arnd Bergmann wrote:
> On Tuesday 24 May 2011, Subhasish Ghosh wrote:
> > Would it be a good approach to first get a basic sensible
> > driver into the tree and then work towards improving and
> > adjusting for future compatibilities.
> 
> The main problem with that is that you cannot really change
> user-visible interfaces after the driver is merged. Anything
> regarding sysfs attributes and firmware file contents needs
> to be fixed. You can however still change in-kernel interfaces
> at a later point without problems.
> 
> > That way we can gradually build towards the perfect driver
> > in steps, rather than digressing far too off suddenly.
> > That would be some source of motivation for me too.
> 
> You can definitely add the driver to drivers/staging/pruss/,
> as the rules for staging drivers are different. I think that
> would indeed be helpful at this point. As soon as all
> interfaces have stabilized, you can then move the individual
> parts to their final location.
> 
> Greg maintains the staging drivers, and he can surely point
> you to a document describing what is required for a driver.

There really are only 3 rules:
	- proper license
	- self-contained in a drivers/staging/DRIVER_NAME/ directory
	- must properly build

> Mainly, this includes having a patch that adds a single
> directory with all the driver files under drivers/staging.
> The driver must be able to compile without errors and you need
> a TODO file listing the remaining issues that prevent you
> from having a non-staging driver.

Ah, forgot the TODO on the list of rules, I'll have to add that next
time.

Someone feel free to send me a patch :)

thanks,

greg k-h
--
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/