public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>,
	linux-omap@vger.kernel.org, gdavis@mvista.com, wim@iguana.be
Subject: Re: [PATCH] watchdog: another ioremap() fix
Date: Thu, 18 Sep 2008 13:10:49 -0700	[thread overview]
Message-ID: <200809181310.49569.david-b@pacbell.net> (raw)
In-Reply-To: <20080918195007.GA14307@flint.arm.linux.org.uk>

On Thursday 18 September 2008, Russell King - ARM Linux wrote:
> What I say to Tony: do you want OMAP to be merged into mainline, or
> don't you.  If you do, do _not_ accept this patch but get the changes
> already in your tree for omap_wdt.c up to Wim, and then get this patch
> there.  Provide the carrot by getting the driver up to date in mainline,
> and the stick by only accepting patches for this driver once they've
> been acked by Wim.  Explicitly ask Wim to ack them for you.
> 
> Then you have one less driver to worry about constantly being out of
> date with mainline.

That sounds like a plan.  One could go further and work
something like the "stable" tree ... not merging into the
OMAP tree until the patch is merged, or at least queued,
for upstream.  Minimal exceptions, if any.  (And not for
this watchdog!)

That should be workable for most drivers; sometimes with
a few arch/arm/plat-omap/include/mach/*.h updates you may
need to ack.  Things like CBUS support (no framework for
that is upstream) are cases where it'd fail.

I'm not exactly in this particular loop except as a gadfly
with relevant insight/background/experience, but I suspect
that a basic goal *MUST* be to avoid having Tony and/or
Russell in the loop unless it's unavoidable.  

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2008-09-18 20:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-18 13:55 [PATCH] watchdog: another ioremap() fix Felipe Balbi
2008-09-18 17:03 ` David Brownell
2008-09-18 17:26   ` Felipe Balbi
2008-09-19  8:06     ` Wim Van Sebroeck
2008-09-18 19:50   ` Russell King - ARM Linux
2008-09-18 20:02     ` Felipe Balbi
2008-09-18 20:15       ` Russell King - ARM Linux
2008-09-18 20:34       ` Russell King - ARM Linux
2008-09-18 20:55         ` Felipe Balbi
2008-09-19  8:30         ` Wim Van Sebroeck
2008-09-18 20:10     ` David Brownell [this message]
2008-09-21 18:20       ` Tony Lindgren
2008-09-18 18:29 ` George G. Davis
2008-09-18 18:40   ` Felipe Balbi
2008-09-18 18:45     ` George G. Davis
2008-09-18 18:49       ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200809181310.49569.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=felipe.balbi@nokia.com \
    --cc=gdavis@mvista.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tony@atomide.com \
    --cc=wim@iguana.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox