public inbox for linux-sh@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH][RFC] drivers: sh: late disabling of clocks
Date: Tue, 21 Jun 2011 06:39:35 +0000	[thread overview]
Message-ID: <20110621063935.GC7920@linux-sh.org> (raw)
In-Reply-To: <20110609091339.14510.31590.sendpatchset@t400s>

On Tue, Jun 21, 2011 at 02:48:44PM +0900, Magnus Damm wrote:
> On Tue, Jun 21, 2011 at 2:27 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Tue, Jun 21, 2011 at 11:29:31AM +0900, Magnus Damm wrote:
> >> On Tue, Jun 21, 2011 at 11:14 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Thu, Jun 16, 2011 at 07:54:38AM +0900, Simon Horman wrote:
> >> >> > Right, I was thinking something along those lines too. The spinlock
> >> >> > should make sure we're serialized.
> >> >>
> >> >> Great. Feel free to take my ideas verbatim if it helps.
> >> >
> >> > Hi Magnus,
> >> >
> >> > have you had time to look into this?
> >>
> >> I have not updated this patch yet, mainly due to lack of feedback. Not
> >> so much due to lack of feedback from you - I appreciate your ideas and
> >> I agree that your rework of the ordering is correct. I'm however still
> >> not sure if other people agree with my approach of delaying the
> >> disable operations until a certain point in time.
> >>
> > Except that's not really how it works. I don't have the time or
> > inclination to go through and provide feedback for every single patch
> > that crosses my inbox. If something has been posted for awhile and has
> > feedback, then it's expected that the feedback is addressed and an
> > updated version is posted. If no other action happens within an arbitrary
> > but not too long period of time, I'll then roll it in to one of my trees
> > for testing (assuming there are no glaring issues with the concept or
> > implementation prior to integration/testing). You've posted multiple
> > versions of the same patches in the past upon receiving feedback, so it's
> > a bit perplexing as to why this time you've simply opted to throw the
> > patch over the fence and do nothing.
> 
> I believe I received some feedback through face-to-face conversations
> earlier, and that feedback was not all that positive. I decided to
> post the code anyway, and Simon kindly provided detailed feedback via
> email about internal ordering. The main idea behind the patch is not
> really changed, so in that area there still is silence.
> 
> I'll resend a new version in a little while. Thanks.
> 
I don't have any particular problems with the approach at least, and at
this point it's really just the locking stuff pointed out by Simon that
is keeping it from being applied. It's obviously somewhat of a hack and
I'm certainly not thrilled by it, but the fact we're forced in to this
position and are entering with undefined state is certainly not your
fault, nor something we can really do much about. We also have half a
dozen syscall ABIs for no good reason because of hardware designer
muppetry, such is life.

Having said that, it might need a bit of fiddling in terms of deciding on
how to enable it or present it to the user, but those are fairly
superficial details that can be worked out once an updated version is
posted.

      parent reply	other threads:[~2011-06-21  6:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09  9:13 [PATCH][RFC] drivers: sh: late disabling of clocks Magnus Damm
2011-06-13  8:59 ` Simon Horman
2011-06-14  6:41 ` Simon Horman
2011-06-15 14:21 ` Magnus Damm
2011-06-15 22:54 ` Simon Horman
2011-06-21  2:14 ` Simon Horman
2011-06-21  2:29 ` Magnus Damm
2011-06-21  3:02 ` Simon Horman
2011-06-21  5:27 ` Paul Mundt
2011-06-21  5:48 ` Magnus Damm
2011-06-21  6:39 ` Paul Mundt [this message]

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=20110621063935.GC7920@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=linux-sh@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