All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>,
	"benoit.cousson@gmail.com" <benoit.cousson@gmail.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 0/4] Cleanup PRM and CM regbit headers
Date: Fri, 5 Jul 2013 00:03:48 -0700	[thread overview]
Message-ID: <20130705070347.GP5523@atomide.com> (raw)
In-Reply-To: <51D65CE8.4050004@ti.com>

* Rajendra Nayak <rnayak@ti.com> [130704 22:49]:
> On Thursday 04 July 2013 10:14 PM, Paul Walmsley wrote:
> > You mentioned that these patches were generated with some kind of awk/grep 
> > scripting.  Can you integrate that in an automated way into the 
> > autogeneration flow?  If the answer is yes, then keep the header.  If the 
> > answer is no, then the header should be dropped.  Benoît, maybe you have 
> > an opinion too?
> 
> Ok, I'll try and integrate those scripts so all this can be done in an
> automated way even for newer SoCs.
> 
> > 
> > As far as whether this should go in -rcX or not, my view is that, as a 
> > matter of policy, large changes like this should wait until v3.12.  Now, 
> > having written that, I also was under the impression that the OMAP5 
> > changes weren't going to be sent upstream unless the total diffstat would 
> > be balanced to roughly zero or negative lines.  As far as I know, that 
> > didn't happen.  So I guess, v3.11-rc it is...  kernel development by 
> > diffstat :-(
> 
> I don't mind these going in -rcX or 3.12, either way is fine.

Removal of unused code should be OK for the early -rc. I doubt that
anybody would object it especially considering that's it's a huge
pile of unused defines that most likely won't ever be needed for
DT based booting.
 
> > Finally, please repost the whole series once you're done with your 
> > changes, as a non-RFC, along with your pull request (if you plan to send 
> > one).  I guess I should be the one to take these, since I wound up taking 
> > the OMAP5 addition...
> 
> :) I thought so too that you should be the one sending the pull.
> I will post these out as non-RFC after I do a clean integration into
> the autogen scripts, and then you can take a call on sending the pull for
> either -rcX or 3.12

I'd prefer to have it done now for the early -rc series. But if it
drags on, we should not merge it during the -rc series.

Regards,

Tony
--
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

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/4] Cleanup PRM and CM regbit headers
Date: Fri, 5 Jul 2013 00:03:48 -0700	[thread overview]
Message-ID: <20130705070347.GP5523@atomide.com> (raw)
In-Reply-To: <51D65CE8.4050004@ti.com>

* Rajendra Nayak <rnayak@ti.com> [130704 22:49]:
> On Thursday 04 July 2013 10:14 PM, Paul Walmsley wrote:
> > You mentioned that these patches were generated with some kind of awk/grep 
> > scripting.  Can you integrate that in an automated way into the 
> > autogeneration flow?  If the answer is yes, then keep the header.  If the 
> > answer is no, then the header should be dropped.  Beno?t, maybe you have 
> > an opinion too?
> 
> Ok, I'll try and integrate those scripts so all this can be done in an
> automated way even for newer SoCs.
> 
> > 
> > As far as whether this should go in -rcX or not, my view is that, as a 
> > matter of policy, large changes like this should wait until v3.12.  Now, 
> > having written that, I also was under the impression that the OMAP5 
> > changes weren't going to be sent upstream unless the total diffstat would 
> > be balanced to roughly zero or negative lines.  As far as I know, that 
> > didn't happen.  So I guess, v3.11-rc it is...  kernel development by 
> > diffstat :-(
> 
> I don't mind these going in -rcX or 3.12, either way is fine.

Removal of unused code should be OK for the early -rc. I doubt that
anybody would object it especially considering that's it's a huge
pile of unused defines that most likely won't ever be needed for
DT based booting.
 
> > Finally, please repost the whole series once you're done with your 
> > changes, as a non-RFC, along with your pull request (if you plan to send 
> > one).  I guess I should be the one to take these, since I wound up taking 
> > the OMAP5 addition...
> 
> :) I thought so too that you should be the one sending the pull.
> I will post these out as non-RFC after I do a clean integration into
> the autogen scripts, and then you can take a call on sending the pull for
> either -rcX or 3.12

I'd prefer to have it done now for the early -rc series. But if it
drags on, we should not merge it during the -rc series.

Regards,

Tony

  reply	other threads:[~2013-07-05  7:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-24 12:15 [RFC 0/4] Cleanup PRM and CM regbit headers Rajendra Nayak
2013-06-24 12:15 ` Rajendra Nayak
2013-06-24 12:15 ` [RFC 1/4] ARM: OMAP2: PRM/CM: Cleanup unused header contents Rajendra Nayak
2013-06-24 12:15 ` [RFC 2/4] ARM: OMAP3: " Rajendra Nayak
2013-06-25  7:14 ` [RFC 0/4] Cleanup PRM and CM regbit headers Tony Lindgren
2013-06-25  7:14   ` Tony Lindgren
2013-06-25  8:43   ` Rajendra Nayak
2013-06-25  8:43     ` Rajendra Nayak
2013-07-04 11:58     ` Tony Lindgren
2013-07-04 11:58       ` Tony Lindgren
2013-07-04 12:14       ` Rajendra Nayak
2013-07-04 12:14         ` Rajendra Nayak
2013-07-04 16:44         ` Paul Walmsley
2013-07-04 16:44           ` Paul Walmsley
2013-07-05  5:43           ` Rajendra Nayak
2013-07-05  5:43             ` Rajendra Nayak
2013-07-05  7:03             ` Tony Lindgren [this message]
2013-07-05  7:03               ` Tony Lindgren

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=20130705070347.GP5523@atomide.com \
    --to=tony@atomide.com \
    --cc=benoit.cousson@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=rnayak@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.