All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: "Gadiyar, Anand" <gadiyar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
	"Pandita, Vikram" <vikram.pandita@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Greg KH <greg@kroah.com>
Subject: Re: [PATCH] OMAP: USB EHCI: Support final revision of USB board
Date: Thu, 18 Sep 2008 13:29:03 -0700	[thread overview]
Message-ID: <200809181329.04429.david-b@pacbell.net> (raw)
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB02C4007ED9@dbde02.ent.ti.com>

On Thursday 18 September 2008, Gadiyar, Anand wrote:
> >		(Hint for TI folk:  why not write the
> > code that way in the first place, avoiding all the delays inherent in
> > writing code you *know* is unsuitable for merging to mainline?)
> 
> Well, there are only a limited number of hours in a day. :)

Bzip2 is a good way to compress things ... can that help
make those hours more productive?  ;)


> Hint taken: that that code was initially written badly is a valid point.

And likewise, I think, that it's not an uncommon way for
things to start out.  The real problem is that such code
then sits in some (OMAP) tree for a long time and never gets
fixed and sent upstream.

One TI engineer (who I won't name!) said to me this year
that he thinks the issue is part of TI's current process.
Paraphrasing:  the code is treated as "done" when it merges
to some OMAP branch ... *NOT* when it goes upstream.  To the
extent that's true, it should get fixed.  For drivers, there
should be no problems doing so.  (Infrastructure is often a
bit different.)


> But fixing it up is a non-trivial effort as is making sure it works. At the time I 
> wrote that e-mail (August 25) I did intend to have it out well before Felipe's
> 11 September plan.
> 
> As they say, the best laid plans of mice and men... At the moment it does
> not look like I'll be able to do this anytime soon.

Right.  That happens.

 
> And if it's going upstream, it needs to be in better shape than it currently is.
> 
> Even assuming that linux-usb decides to take it in it's current shape, it's 
> definitely not going to help things when the OHCI driver comes in. And if
> I'm going to be doing that cleanup anyway, I might as well get it right the
> first time. Correct?

Unless that stretches the EHCI merge out too much.  Drivers sitting
around outside of mainline for a long time (a year or more) make
trouble.  Updates to mainline generally don't make trouble.

 
> I'm going to be re-arranging this code, writing it the way it ought to have
> been the first time. But please don't expect this tomorrow.

No, I'm not ... as I noted!  Though I'd hope it's ready to push upstream
in the 2.6.29-rc0 window...

I'm just piling on with a few observations about a process problem here.
We've seen versions of this for a long time now.  Once you achieve that
re-arrangement ... it'd be nicer all around (for you, for me, for everyone)
if the problem came up less regularly in the future.

- 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:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-30 14:03 [PATCH] OMAP: USB EHCI: Support final revision of USB board Pandita, Vikram
2008-08-05 10:46 ` Tony Lindgren
2008-08-21 12:49   ` Gadiyar, Anand
2008-08-23 23:22     ` Tony Lindgren
2008-08-25  4:40       ` Gadiyar, Anand
2008-09-18 19:22       ` David Brownell
2008-09-18 19:49         ` Gadiyar, Anand
2008-09-18 20:00           ` Måns Rullgård
2008-09-18 20:06             ` Gadiyar, Anand
2008-09-18 20:29           ` David Brownell [this message]

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=200809181329.04429.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=gadiyar@ti.com \
    --cc=greg@kroah.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=vikram.pandita@ti.com \
    /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.