From: Tony Lindgren <tony@atomide.com>
To: David Brownell <david-b@pacbell.net>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
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: Sun, 21 Sep 2008 11:20:09 -0700 [thread overview]
Message-ID: <20080921182008.GB7961@atomide.com> (raw)
In-Reply-To: <200809181310.49569.david-b@pacbell.net>
* David Brownell <david-b@pacbell.net> [080918 13:11]:
> 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.
Been offline few days, glad to see the watchdog updates moving forward :)
Yes I agree we should deal with drivers directly on the appropriate
mailing lists. And then have them fall downstream to l-o tree.
We can use l-o tree for testing and integration, but let's add
a new rule like Russell is suggesting: Let's get at least an ack from
the appropriate maintainer before we apply the patches into l-o tree.
And of course we've already moved quite a bit of the driver development
to the right mailing lists like USB (except ehci-hcd, grr) and audio.
Cheers,
Tony
--
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
next prev parent reply other threads:[~2008-09-21 18:17 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
2008-09-21 18:20 ` Tony Lindgren [this message]
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=20080921182008.GB7961@atomide.com \
--to=tony@atomide.com \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.