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: <201105241440.34854.arnd@arndb.de>
Date:	Tue, 24 May 2011 14:40:34 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Subhasish Ghosh" <subhasish@...tralsolutions.com>
Cc:	"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>, Greg KH <greg@...ah.com>
Subject: Re: [PATCH v4 01/11] mfd: add pruss mfd driver

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.
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.

I think the list will be relatively short, given that you
have made a lot of progress and the driver is now essentially
ready, aside from a few details and the big question of
how the firmware should be configured and loaded.

	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