All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Gatliff <bgat@billgatliff.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	viresh kumar <viresh.kumar@st.com>,
	Shawn Guo <shawn.guo@linaro.org>,
	Ryan Mallon <ryan@bluewatersys.com>
Subject: Re: [PATCH 1/3] PWM: add pwm framework support
Date: Thu, 30 Jun 2011 11:17:54 -0500	[thread overview]
Message-ID: <BANLkTin_htv2z3D9Bbf6N8Y7UKFRvPtvOg@mail.gmail.com> (raw)
In-Reply-To: <201106301441.24493.arnd@arndb.de>

Guys:

On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> A lot of people want to see a framework get merged, and I think it's
> great that Sascha has volunteered to do the work to push that
> through this time, especially since you have not been able to
> finish your work.

Sascha is wasting his time by reinventing the wheel.  He's traveling
over exactly the same path I have already covered.  In fact, some of
his reviewer comments are almost word-for-word the same as those I
have received and addressed in the past.

My patches were always kept current in this mailing list and others,
and Sascha clearly has the skills necessary to make improvements and
corrections should he have chosen to do so.

> What I think would be the best plan forward is to merge Sascha's
> patches as soon as we can, then get all currently existing pwm
> drivers converted to that and moved to drivers/pwm, and finally
> do the interface changes that you have proposed earlier.

That's a real duplication of work.  That makes no sense.

> I would also hope that you can give constructive feedback to
> the submission and point out potential problems that you see
> where the code should be changed now in order to make your
> interface changes more easy later.

My code has already moved past that point.  And if I had the time to
evaluate and improve Sascha's patches, I would have the time to finish
my own.  Sascha is more than welcome to apply his efforts to the
preexisting PWM API patches already present in the LKML archives.

> I realize that it's annoying to spend a lot of time on a specific
> implementation and then see competing code get merged.

Annoyed isn't the word you are looking for.

My code has been reviewed, tested and actively used as posted in LKML
by several reviewers (including myself) in actual hardware.  We are
consciously choosing to discard a known entity and restart the whole
process with new code.  That's a waste of everyone's time and risk
exposure.

I don't consider Sascha's code to be "competing" with mine, as
apparently nobody has bothered to consider one against the other.


> Unfortunately,
> this happens all the time, and the code we merge is often not
> the one that has had the most effort spent on it, but the one that
> looks most promising at the time when it gets merged.

Your definition of "promsing" apparently correlates with "new and shiny".


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

WARNING: multiple messages have this Message-ID (diff)
From: bgat@billgatliff.com (Bill Gatliff)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] PWM: add pwm framework support
Date: Thu, 30 Jun 2011 11:17:54 -0500	[thread overview]
Message-ID: <BANLkTin_htv2z3D9Bbf6N8Y7UKFRvPtvOg@mail.gmail.com> (raw)
In-Reply-To: <201106301441.24493.arnd@arndb.de>

Guys:

On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> A lot of people want to see a framework get merged, and I think it's
> great that Sascha has volunteered to do the work to push that
> through this time, especially since you have not been able to
> finish your work.

Sascha is wasting his time by reinventing the wheel.  He's traveling
over exactly the same path I have already covered.  In fact, some of
his reviewer comments are almost word-for-word the same as those I
have received and addressed in the past.

My patches were always kept current in this mailing list and others,
and Sascha clearly has the skills necessary to make improvements and
corrections should he have chosen to do so.

> What I think would be the best plan forward is to merge Sascha's
> patches as soon as we can, then get all currently existing pwm
> drivers converted to that and moved to drivers/pwm, and finally
> do the interface changes that you have proposed earlier.

That's a real duplication of work.  That makes no sense.

> I would also hope that you can give constructive feedback to
> the submission and point out potential problems that you see
> where the code should be changed now in order to make your
> interface changes more easy later.

My code has already moved past that point.  And if I had the time to
evaluate and improve Sascha's patches, I would have the time to finish
my own.  Sascha is more than welcome to apply his efforts to the
preexisting PWM API patches already present in the LKML archives.

> I realize that it's annoying to spend a lot of time on a specific
> implementation and then see competing code get merged.

Annoyed isn't the word you are looking for.

My code has been reviewed, tested and actively used as posted in LKML
by several reviewers (including myself) in actual hardware.  We are
consciously choosing to discard a known entity and restart the whole
process with new code.  That's a waste of everyone's time and risk
exposure.

I don't consider Sascha's code to be "competing" with mine, as
apparently nobody has bothered to consider one against the other.


> Unfortunately,
> this happens all the time, and the code we merge is often not
> the one that has had the most effort spent on it, but the one that
> looks most promising at the time when it gets merged.

Your definition of "promsing" apparently correlates with "new and shiny".


b.g.
-- 
Bill Gatliff
bgat at billgatliff.com

  reply	other threads:[~2011-06-30 16:17 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 10:41 [PATCH v3] implement a generic PWM framework Sascha Hauer
2011-06-30 10:41 ` Sascha Hauer
2011-06-30 10:41 ` [PATCH 1/3] PWM: add pwm framework support Sascha Hauer
2011-06-30 10:41   ` Sascha Hauer
2011-06-30 11:07   ` Bill Gatliff
2011-06-30 11:07     ` Bill Gatliff
2011-06-30 12:41     ` Arnd Bergmann
2011-06-30 12:41       ` Arnd Bergmann
2011-06-30 16:17       ` Bill Gatliff [this message]
2011-06-30 16:17         ` Bill Gatliff
2011-06-30 17:02         ` Sascha Hauer
2011-06-30 17:02           ` Sascha Hauer
2011-06-30 19:45           ` Bill Gatliff
2011-06-30 19:45             ` Bill Gatliff
2011-06-30 23:24           ` Ryan Mallon
2011-06-30 23:24             ` Ryan Mallon
2011-07-01  0:33             ` H Hartley Sweeten
2011-07-01  0:33               ` H Hartley Sweeten
2011-07-01  0:55               ` Mike Frysinger
2011-07-01  0:55                 ` Mike Frysinger
2011-07-01  7:37             ` Sascha Hauer
2011-07-01  7:37               ` Sascha Hauer
2011-07-01  8:28               ` Ryan Mallon
2011-07-01  8:28                 ` Ryan Mallon
2011-07-01  8:54                 ` Sascha Hauer
2011-07-01  8:54                   ` Sascha Hauer
2011-07-02  0:40                   ` Ryan Mallon
2011-07-02  0:40                     ` Ryan Mallon
2011-07-04  7:55                     ` Sascha Hauer
2011-07-04  7:55                       ` Sascha Hauer
2011-07-04  8:50                       ` Dmitry Eremin-Solenikov
2011-07-04 10:43                       ` Ryan Mallon
2011-07-04 10:43                         ` Ryan Mallon
2011-07-04 11:05                         ` Kurt Van Dijck
2011-07-04 13:53                           ` Arnd Bergmann
2011-07-04 13:53                             ` Arnd Bergmann
2011-07-04 14:19                             ` Kurt Van Dijck
2011-07-04 12:43                         ` Sascha Hauer
2011-07-04 12:43                           ` Sascha Hauer
2011-07-04 14:07                           ` Arnd Bergmann
2011-07-04 14:07                             ` Arnd Bergmann
2011-12-07  8:53                             ` Thierry Reding
2011-12-07  8:53                               ` Thierry Reding
2011-12-07  9:07                               ` Sascha Hauer
2011-12-07  9:07                                 ` Sascha Hauer
2011-12-14 10:03                                 ` Thierry Reding
2011-12-14 10:03                                   ` Thierry Reding
2011-12-14 11:37                                   ` Sascha Hauer
2011-12-14 11:37                                     ` Sascha Hauer
2011-07-01  9:49               ` Dmitry Eremin-Solenikov
2011-06-30 10:41 ` [PATCH 2/3] ARM mxs: adjust pwm resources to what the driver expects Sascha Hauer
2011-06-30 10:41   ` Sascha Hauer
2011-06-30 11:30   ` Arnd Bergmann
2011-06-30 11:30     ` Arnd Bergmann
2011-06-30 10:41 ` [PATCH 3/3] pwm: Add a i.MX23/28 pwm driver Sascha Hauer
2011-06-30 10:41   ` Sascha Hauer
2011-06-30 11:42   ` Arnd Bergmann
2011-06-30 11:42     ` Arnd Bergmann
2011-06-30 15:11     ` Sascha Hauer
2011-06-30 15:11       ` Sascha Hauer

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=BANLkTin_htv2z3D9Bbf6N8Y7UKFRvPtvOg@mail.gmail.com \
    --to=bgat@billgatliff.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryan@bluewatersys.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawn.guo@linaro.org \
    --cc=viresh.kumar@st.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.