All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Alexander Clouter <alex@digriz.org.uk>
Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
Date: Thu, 07 Apr 2011 23:31:08 +0200	[thread overview]
Message-ID: <4D9E2D1C.7070102@ahsoftware.de> (raw)
In-Reply-To: <toa078-0do.ln1@chipmunk.wormnet.eu>

Am 07.04.2011 10:55, schrieb Alexander Clouter:
> In gmane.linux.kernel Alexander Holler<holler@ahsoftware.de>  wrote:
>>
>> Sorry, I don't feel the need to waste my time prodcuing patches to get
>> them called "abominations". Which means my willingness to post further
>> patches just got below zero.
>>
> In a posting from Nico before you got offended it was explained to you
> *why* it was a Bad Idea(tm) and that that sort of thing simply does not
> work.  As a game, is it really a situation with *zero* probability of
> occuring that someone might produce a kirkwood/Sheeva flavoured board
> with only 128MB RAM?
>
> As well as a willingness to 'produce' patches (which to be frank
> *anyone* can do[1])...the hard part is producing *good* patches.  To
> produce good patches you need to read and understand the wisdom you get
> back from the mailing lists you post to.  If you do not understand the
> reasoning, ask.
>
> This is why you see [PATCHv${BIGNUM}] so often in a number of mailing
> lists.  If you are not willing to accept *everyone*, including yourself,
> writes crap code...well the value of your patches falls below zero.

Requiring a machine ID and the needed stuff to handle that for a board 
which just is using two GPIOs different than another board is why the 
ARM tree exploded. And requiring a machine ID just to follow the rule 
that a machine ID is much better than some pretty unique hw feature is 
in my humble opinion senseless and that the resulting code is more 
readable and better to maintain is a myth.

Sorry that I wanted to help there. Will not try it again.

Regards,

Alexander

WARNING: multiple messages have this Message-ID (diff)
From: holler@ahsoftware.de (Alexander Holler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
Date: Thu, 07 Apr 2011 23:31:08 +0200	[thread overview]
Message-ID: <4D9E2D1C.7070102@ahsoftware.de> (raw)
In-Reply-To: <toa078-0do.ln1@chipmunk.wormnet.eu>

Am 07.04.2011 10:55, schrieb Alexander Clouter:
> In gmane.linux.kernel Alexander Holler<holler@ahsoftware.de>  wrote:
>>
>> Sorry, I don't feel the need to waste my time prodcuing patches to get
>> them called "abominations". Which means my willingness to post further
>> patches just got below zero.
>>
> In a posting from Nico before you got offended it was explained to you
> *why* it was a Bad Idea(tm) and that that sort of thing simply does not
> work.  As a game, is it really a situation with *zero* probability of
> occuring that someone might produce a kirkwood/Sheeva flavoured board
> with only 128MB RAM?
>
> As well as a willingness to 'produce' patches (which to be frank
> *anyone* can do[1])...the hard part is producing *good* patches.  To
> produce good patches you need to read and understand the wisdom you get
> back from the mailing lists you post to.  If you do not understand the
> reasoning, ask.
>
> This is why you see [PATCHv${BIGNUM}] so often in a number of mailing
> lists.  If you are not willing to accept *everyone*, including yourself,
> writes crap code...well the value of your patches falls below zero.

Requiring a machine ID and the needed stuff to handle that for a board 
which just is using two GPIOs different than another board is why the 
ARM tree exploded. And requiring a machine ID just to follow the rule 
that a machine ID is much better than some pretty unique hw feature is 
in my humble opinion senseless and that the resulting code is more 
readable and better to maintain is a myth.

Sorry that I wanted to help there. Will not try it again.

Regards,

Alexander

  reply	other threads:[~2011-04-07 21:31 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-06 20:35 [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and Seagate DockStars Alexander Holler
2011-04-06 20:35 ` Alexander Holler
2011-04-06 20:35 ` [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size Alexander Holler
2011-04-06 20:35   ` Alexander Holler
2011-04-06 21:44   ` Nicolas Pitre
2011-04-06 21:44     ` Nicolas Pitre
2011-04-06 22:45     ` Alexander Holler
2011-04-06 22:45       ` Alexander Holler
2011-04-06 23:01       ` Nicolas Pitre
2011-04-06 23:01         ` Nicolas Pitre
2011-04-06 23:22         ` Alexander Holler
2011-04-06 23:22           ` Alexander Holler
2011-04-07  2:55           ` Nicolas Pitre
2011-04-07  2:55             ` Nicolas Pitre
2011-04-07  8:55           ` Alexander Clouter
2011-04-07 21:31             ` Alexander Holler [this message]
2011-04-07 21:31               ` Alexander Holler
2011-04-07 21:44               ` Alexander Clouter
2011-04-07 21:44                 ` Alexander Clouter
2011-04-07 21:59                 ` Alexander Holler
2011-04-07 21:59                   ` Alexander Holler
2011-04-07 22:08               ` Russell King - ARM Linux
2011-04-07 22:08                 ` Russell King - ARM Linux
2011-04-07 23:04                 ` Alexander Holler
2011-04-07 23:04                   ` Alexander Holler
2011-04-08  7:24                   ` Russell King - ARM Linux
2011-04-08  7:24                     ` Russell King - ARM Linux
2011-04-08  8:38                     ` Alexander Holler
2011-04-08  8:38                       ` Alexander Holler
2011-04-09  8:29                   ` Bernd Petrovitsch
2011-04-09  8:29                     ` Bernd Petrovitsch
2011-04-10 18:14                     ` Alexander Holler
2011-04-10 18:14                       ` Alexander Holler
2011-04-10 19:29                       ` Alexander Holler
2011-04-10 19:29                         ` Alexander Holler
2011-04-06 23:23         ` Eric Cooper
2011-04-06 23:23           ` Eric Cooper
2011-04-06 20:35 ` [PATCH 2/2] ARM: Remove machine type dockstar (use sheevaplug instead) Alexander Holler
2011-04-06 20:35   ` Alexander Holler
2011-04-06 21:02   ` Nicolas Pitre
2011-04-06 21:02     ` Nicolas Pitre
2011-04-06 21:43     ` Alexander Holler
2011-04-06 21:43       ` Alexander Holler
2011-04-06 22:50 ` [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and Seagate DockStars Nico Erfurth
2011-04-06 22:50   ` Nico Erfurth
2011-04-07  9:20   ` Alexander Holler
2011-04-07  9:20     ` Alexander Holler
2011-04-07  9:37     ` Nico Erfurth
2011-04-07  9:37       ` Nico Erfurth
2011-04-07  9:44       ` Alexander Holler
2011-04-07  9:44         ` Alexander Holler
2011-04-07 17:39         ` Russell King - ARM Linux
2011-04-07 17:39           ` Russell King - ARM Linux
2011-04-08  3:38           ` Alexander Holler
2011-04-08  3:38             ` Alexander Holler

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=4D9E2D1C.7070102@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=alex@digriz.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@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 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.