linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
Date: Wed, 30 Apr 2014 11:14:36 +0000	[thread overview]
Message-ID: <5360DB1C.3020400@ti.com> (raw)
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

On 24/04/14 19:35, Alexander Shiyan wrote:

>> The right way to do it is, as I wrote above, by gradually changing the
>> old driver with a patch series. And my question is, why not do it that
>> way? Then it would be possible to review the patches one by one, seeing
>> what has changed.
> 
> "gradually changing"...
> I repeat that this is not an old modified driver, but written new.

Yes, I understand that. Again, my question is, why didn't you modify the
old driver? That's how things should normally be done. Instead, you made
a totally new one, making proper review against the old driver impossible.

> if you imagine a new file as a diff to the old, this can be clearly seen.
> 
> There is no reason to waste time on a series of changes since I
> can not even check these changes on real hardware, but only in the
> last stage when the driver will be the current version.

Hmm what? So is the old driver totally broken, and cannot be used at the
moment? Or why you can't test on real hardware?

Note that I don't know anything about the fb hardware in question, nor
the driver. Maybe there's a valid reason to write a new driver from
scratch. But there very rarely is.

And "because I already wrote a new driver, and it's a waste of time for
me to throw away my work and patch the old one", is not a very good reason.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2014-04-30 11:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-12  6:53 [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver Alexander Shiyan
2014-04-24  5:03 ` Alexander Shiyan
2014-04-24  7:57 ` Tomi Valkeinen
2014-04-24  8:39 ` Tomi Valkeinen
2014-04-30 11:14 ` Tomi Valkeinen [this message]
2014-05-05  5:06 ` Olof Johansson
2014-05-07  9:40 ` Tomi Valkeinen
2014-05-08 10:14 ` Tomi Valkeinen
2014-05-16 22:56 ` Olof Johansson
2014-05-23 12:31 ` Tomi Valkeinen
2014-05-23 12:43 ` Tomi Valkeinen
2014-05-23 13:48 ` Arnd Bergmann
2014-05-23 14:10 ` Tomi Valkeinen
2014-05-23 14:14 ` Arnd Bergmann
2014-05-23 14:26 ` Tomi Valkeinen
2014-05-23 14:32 ` Tomi Valkeinen

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=5360DB1C.3020400@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).