linux-kernel - Re: [PATCH 3/5] watchdog: cleanup a bit omap

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: <200809211901.19080.david-b@pacbell.net>
Date:	Sun, 21 Sep 2008 19:01:18 -0700
From:	David Brownell <david-b@...bell.net>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Wim Van Sebroeck <wim@...ana.be>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"George G. Davis" <gdavis@...sta.com>
Subject: Re: [PATCH 3/5] watchdog: cleanup a bit omap_wdt.c

On Sunday 21 September 2008, Tony Lindgren wrote:
> Hey, you gotta give Dave some credit! Dave's been polishing tons of omap
> code in addition to the USB, at least I2C, gpio, SPI come to mind. Not to
> mention all the blinking leds!

Blinky leds can be the first visible sign of progress!  ;)

> Regarding getting an army of people to fix code, we need to start
> following another standard policy: All drivers must have a MAINTAINER
> who is capable of fixing things, and ideally doing things the right
> way from the start.

Which includes pushing their code into mainline ... and getting
acks (as you noted elsewhere) from the subsystem maintainer to
help avoid going too far astray.

In some cases that implies getting some new frameworks into mainline,
or updating the ones that are there.  The ALSA-SOC stuff has been
a win there, in terms of maintainable code ... the previous solution
involved very little reuse of the funky codec and data stream code,
while now that's far more practical.

Similarly I2C driver model support, GPIO expander infrastructure,
and SPI:  instead of scattering board-specific code in drivers all
over the source tree, it can now be split out fairly cleanly.  That
makes maintainers much happier.

- Dave
--
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/