All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	devicetree@vger.kernel.org,
	Tyrel Datwyler <tyreld@linux.vnet.ibm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-renesas-soc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Rob Herring <robh+dt@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues
Date: Thu, 25 Jan 2018 16:42:51 -0800	[thread overview]
Message-ID: <b4396070-accc-1fe2-21a6-cefaddeeb06c@gmail.com> (raw)
In-Reply-To: <20180125231219.mkgai2yurkj3f7ph@ninjato>

On 01/25/18 15:12, Wolfram Sang wrote:
> Frank,
> 
> here seems to be a misunderstanding going on. I don't want to push this
> patch upstream against all odds. I merely wanted to find out what the
> status of this patch is. Because one possibility was that it had just
> been forgotten...
> 
>>> So, I thought reposting would be a good way of finding out if your
>>> concerns were addressed in the discussion or not. If I overlooked

Marking a patch as RFC (as you mention just below here) is very different
than explicitly stating something like: Frank, you had concerns with
version 1, were your concerns addressed in the thread about version 1?

You mention below that adding RFC to the title was providing the
information that I needed.  I am saying that the communication was
not clear, was implied at best, and should have be more explicit.

I actually didn't even notice that the patch title had changed from
not an RFC, to being an RFC, so the subtle clue went right over my
head.  I just treated it as I would any RFC patch.


>> Then you should have stated that there were concerns raised in the
>> discussion and asked me if my concerns were addressed.
> 
> From my perspective, I have done that:
> 
> I marked the patch as RFC. I put you on the CC list. I asked about the
> possibility of applying it. It was not very elaborate, but hey, this is
> just a simple debugging patch :)

After reading through the original patch thread, I did not think that
the issues raised had been fully addressed.  You read the thread and
thought they had.  No big deal on coming to different conclusions.

I think you and I are talking past each other a little bit.  My
comments in the email you are responding to are because I don't
think that the previous emails have been as clear as you think.
I could read between the lines and see how you think that you
were being clear.  But from my perspective, I'm asking for more
explicit statements and less implied statements.

My first real response (the response that pointed out that Rob had
made an observation / suggestion that was not responded to) was coming
from the perspective that the issues in the first thread had not been
fully addressed.

As I was writing that response, I felt that I might as well do a review,
even though I thought the previous thread was dangling.  Which led to a
lot of issues and a few more emails pointing them out.


> I totally would have accepted a high level "No, that won't fly
> because...". Or a high level "This and that would need a change". Or
> something like that. I intentionally sent this out as RFC because I know
> there is some testing missing. I wanted to know if it is worth taking
> further steps with this patch.
> 
> So, I simply wanted to know if you (still) have fundamental issues with
> the patch?

It would have been good if you had simply stated so in exactly those
words.  I did not read the original email as saying that.  I read
the original email as saying (my paraphrase) "please apply it".  You
did _not_ use the words that I paraphrased, you actually said
"So what about applying it?".  I misunderstood what you were trying
to say.  I apologize for that.


> That needs to be discussed first before we go into coding
> details. I think it is fine to not apply it if there are reasons. I'd
> like to know them, however, for a better understanding.

Too late now. :-)  I've already done the reviewing and provided all
of the reasons that are show stoppers for the patch and how to fix.

One thing that I did not mention in this thread  is that I have an
aversion to using ftrace for what is purely debugging data (which
this is) because there is a danger that trace points become user
space ABI.  That is a whole long discussion that we do not have to
have because I am not subjecting this patch to that objection.


> For me, this is a super-super-side project, so if it causes too much
> hazzle, I just leave it here and know interested people can find it
> easier now. But if it could be applied with a sane amount of effort, I
> was offering that.
> 
> Was that understandable?

I think so.  And in return?  We can always talk more at the next
conference if you want.

-Frank

> 
> Kind regards,
> 
>    Wolfram
> 

  reply	other threads:[~2018-01-26  0:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-21 14:31 [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues Wolfram Sang
2018-01-21 14:31 ` [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle Wolfram Sang
2018-01-21 22:01   ` Steven Rostedt
2018-01-21 22:01     ` Steven Rostedt
2018-01-25  6:48   ` Frank Rowand
2018-01-25  6:58     ` Frank Rowand
2018-01-25  8:01     ` Geert Uytterhoeven
2018-01-25  8:01       ` Geert Uytterhoeven
2018-01-25  8:30       ` Frank Rowand
2018-01-25 22:40     ` Tyrel Datwyler
2018-01-25 23:31       ` Frank Rowand
2018-01-25 23:31         ` Frank Rowand
2018-01-25  8:32   ` Frank Rowand
2018-01-22  8:43 ` [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues Frank Rowand
2018-01-22 11:49   ` Wolfram Sang
2018-01-23 12:11     ` Michael Ellerman
2018-01-23 19:53       ` Frank Rowand
2018-01-25  6:47     ` Frank Rowand
2018-01-25 23:12       ` Wolfram Sang
2018-01-25 23:12         ` Wolfram Sang
2018-01-26  0:42         ` Frank Rowand [this message]
2018-01-25  6:48 ` Frank Rowand
2018-01-25  6:55 ` Frank Rowand
2018-01-25  6:55   ` Frank Rowand
2018-01-25 11:03   ` Steven Rostedt
2018-01-25 21:49     ` Frank Rowand
2018-01-25 23:14       ` Wolfram Sang
2018-01-25 23:14         ` Wolfram Sang
2018-01-26  0:46         ` Frank Rowand
2018-01-26  0:46           ` Frank Rowand
2018-02-01 17:10           ` Steven Rostedt
2018-01-25 23:53       ` Tyrel Datwyler
2018-01-26  1:08         ` Frank Rowand

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=b4396070-accc-1fe2-21a6-cefaddeeb06c@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=robh+dt@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tyreld@linux.vnet.ibm.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@the-dreams.de \
    /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.