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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox