[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200708060907.02506.david-b@pacbell.net>
Date: Mon, 6 Aug 2007 09:07:02 -0700
From: David Brownell <david-b@...bell.net>
To: "Mike Frysinger" <vapier.adi@...il.com>, bryan.wu@...log.com
Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] Blackfin arch update for 2.6.23
On Sunday 05 August 2007, Mike Frysinger wrote:
> On 8/5/07, Bryan Wu <bryan.wu@...log.com> wrote:
> > Bryan Wu (4):
> > Blackfin SPI driver: Initial supporting BF54x in SPI driver
> >
> > Michael Hennerich (11):
> > Blackfin arch: store labels so we later know who allocated GPIO/Peripheral resources
> > Blackfin arch: add peripheral resource allocation support
> > Blackfin arch: Add label to call new GPIO API
> > Blackfin SPI driver: Make BF54x SPI work and add support for portmux API
> > Blackfin SPI driver: use new GPIO API and add error handling
>
> i think this is the sort of thing Linus wants left for initial merge windows ?
What, merging patches that have never even been seen by the relevant
subsystem maintainer(s)?
I've never seen any of those SPI patches before, and am not inclined
to try plucking three of them out of a composite patch for a separate
review ...
Same goes for GPIO, for that matter. It's harder to goof those up,
but it's still possible. If those were reviewed I personally might
be inclined to OK merges after RC1; GPIOs get used almost everywhere.
(Pretty much as Bryan commented...) Those look more like portmux
changes than GPIO changes though.
- 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/
Powered by blists - more mailing lists