All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/8] ARM: shmobile: Conditionally select SMSC_PHY
Date: Fri, 10 Jan 2014 00:54:27 +0000	[thread overview]
Message-ID: <20140110005427.GD22965@verge.net.au> (raw)
In-Reply-To: <201401091215.33255.arnd@arndb.de>

On Thu, Jan 09, 2014 at 12:15:32PM +0100, Arnd Bergmann wrote:
> On Thursday 09 January 2014, Simon Horman wrote:
> > On Tue, Jan 07, 2014 at 05:48:00PM +0900, Simon Horman wrote:
> > > Select the SMSC_PHY if ethernet is enabled on shmbile boards
> > > that have an SMSC phy. This allows the SMSC-specific phy driver
> > > to be used rather than relying on generic phy code.
> > > 
> > > Based on the renesas-devel-v3.13-rc7-20140107 tag
> > > of my renesas tree.
> > 
> > I have queued up these changes.
> > 
> 
> I don't have an objection to the patches themselves, but a general
> feeling that it would be better to have larger combined patches than
> splitting them out per board.
> 
> I'm cautious with this comment because most people seem to do the
> opposite and combine too many things into large patches, but I think
> when you have identical changeset comments and change the same Kconfig
> file in all of them, you can save yourself and the reviewers some work.

Thanks, I think that is a reasonable comment.

I expected to be more variance between the changes. And in particular
I expected more than one PHY driver to be involved. But as I checked
the hardware on each board, wrote a patch and tested it turned
out that SMSC was used by all the boards. So I was left with a stack
of very similar patches.

In hindsight it might have been better to squash them at that point.
But I too am wary of combining too many things into one patch and
ended up leaning too far the other way.

As I have already queued them up I'd rather not squash them at this point.

WARNING: multiple messages have this Message-ID (diff)
From: horms@verge.net.au (Simon Horman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/8] ARM: shmobile: Conditionally select SMSC_PHY
Date: Fri, 10 Jan 2014 09:54:27 +0900	[thread overview]
Message-ID: <20140110005427.GD22965@verge.net.au> (raw)
In-Reply-To: <201401091215.33255.arnd@arndb.de>

On Thu, Jan 09, 2014 at 12:15:32PM +0100, Arnd Bergmann wrote:
> On Thursday 09 January 2014, Simon Horman wrote:
> > On Tue, Jan 07, 2014 at 05:48:00PM +0900, Simon Horman wrote:
> > > Select the SMSC_PHY if ethernet is enabled on shmbile boards
> > > that have an SMSC phy. This allows the SMSC-specific phy driver
> > > to be used rather than relying on generic phy code.
> > > 
> > > Based on the renesas-devel-v3.13-rc7-20140107 tag
> > > of my renesas tree.
> > 
> > I have queued up these changes.
> > 
> 
> I don't have an objection to the patches themselves, but a general
> feeling that it would be better to have larger combined patches than
> splitting them out per board.
> 
> I'm cautious with this comment because most people seem to do the
> opposite and combine too many things into large patches, but I think
> when you have identical changeset comments and change the same Kconfig
> file in all of them, you can save yourself and the reviewers some work.

Thanks, I think that is a reasonable comment.

I expected to be more variance between the changes. And in particular
I expected more than one PHY driver to be involved. But as I checked
the hardware on each board, wrote a patch and tested it turned
out that SMSC was used by all the boards. So I was left with a stack
of very similar patches.

In hindsight it might have been better to squash them at that point.
But I too am wary of combining too many things into one patch and
ended up leaning too far the other way.

As I have already queued them up I'd rather not squash them at this point.

  reply	other threads:[~2014-01-10  0:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-07  8:48 [PATCH 0/8] ARM: shmobile: Conditionally select SMSC_PHY Simon Horman
2014-01-07  8:48 ` Simon Horman
2014-01-07  8:48 ` [PATCH 1/8] ARM: shmobile: ape6evm: " Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-07  8:48 ` [PATCH 2/8] ARM: shmobile: armadillo800eva: " Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-07  8:48 ` [PATCH 3/8] ARM: shmobile: bockw: Sort Kconfig node's selections Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-07  8:48 ` [PATCH 4/8] ARM: shmobile: bockw: Conditionally select SMSC_PHY Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-07  8:48 ` [PATCH 5/8] ARM: shmobile: kzm9d: " Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-07  8:48 ` [PATCH 6/8] ARM: shmobile: kzm9g: " Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-07  8:48 ` [PATCH 7/8] ARM: shmobile: mackerel: " Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-07  8:48 ` [PATCH 8/8] ARM: shmobile: marzen: " Simon Horman
2014-01-07  8:48   ` Simon Horman
2014-01-09  5:13 ` [PATCH 0/8] ARM: shmobile: " Simon Horman
2014-01-09  5:13   ` Simon Horman
2014-01-09 11:15   ` Arnd Bergmann
2014-01-09 11:15     ` Arnd Bergmann
2014-01-10  0:54     ` Simon Horman [this message]
2014-01-10  0:54       ` Simon Horman
2014-01-10 19:02       ` Arnd Bergmann
2014-01-10 19:02         ` Arnd Bergmann
2014-02-04  6:47 ` Simon Horman
2014-02-04  6:47   ` Simon Horman
2014-02-06  8:56   ` Simon Horman
2014-02-06  8:56     ` Simon Horman

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=20140110005427.GD22965@verge.net.au \
    --to=horms@verge.net.au \
    --cc=linux-arm-kernel@lists.infradead.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.