From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [PATCH v2] Revert "i2c: rcar: remove spinlock"
Date: Tue, 02 Sep 2014 22:10:01 +0400 [thread overview]
Message-ID: <540607F9.4060802@cogentembedded.com> (raw)
In-Reply-To: <20140902174548.GB10355@katana>
On 09/02/2014 09:45 PM, Wolfram Sang wrote:
>>> I don't see why. If we have two patches, the state inbetween them is
>>> broken.
>> Even so, it has always been broken, we don't make it more broken by
>> reverting your change.
> Yes. Still, if I send something to *stable*, less broken is not an
> option for me, if I know there is a fix possible. And we are at -rc3
> now, so there is still time for that.
Not as much time for me since I'm leaving for vacations at the start of
the next week. And I have other areas to care about before that.
>>> And we don't have two patches yet, just the revert. So, the
>> I'm going to consider the spinlock issue ASAP, after I check whether the
>> I2C clock frequency really has any influence on the unexpected read NACK
>> issue I've been chasing for several days.
> Good luck with that! Such bugs are truly annoying :(
Sigh, that whole issue looks like hardware bug to me (the vendor kernel
reportedly doesn't have it though)... overall, this hardware seems excessively
buggy, despite I2C protocol is not really rocket science.
>> Your patch removing the spinlock went into 3.16 only but we'd have to
>> backport the assumed single patch to the -stable kernels older than that.
>> This means that I'd have to provide the "delta" patch (i.e. the separate
>> patch that I'd like to provide now atop of the revert) for these kernels
>> instead since the original single patch wouldn't apply anyway.
> With all my changes in 3.16, I wonder if the patch with your addition to
> the revert will apply anyhow.
Resolution of the context issues is different from the patch principally
not applying as the changes it has are already there.
> But, okay, you send two patches, and I
> will decide how I apply them and deal with delta-patches. Okay?
So you mean that I need to repost the revert? I'm OK with that since the
context has most probably changed with my recent patch...
> All the best,
> Wolfram
WBR, Sergei
next prev parent reply other threads:[~2014-09-02 18:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 20:44 [PATCH v2] Revert "i2c: rcar: remove spinlock" Sergei Shtylyov
2014-08-24 6:45 ` Wolfram Sang
2014-08-24 11:30 ` Sergei Shtylyov
[not found] ` <53F9CCE7.3010006-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2014-08-25 3:40 ` Wolfram Sang
2014-08-25 11:35 ` Sergei Shtylyov
[not found] ` <53FB1F90.6080704-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2014-08-25 14:33 ` Wolfram Sang
2014-09-02 17:13 ` Sergei Shtylyov
2014-09-02 17:18 ` Wolfram Sang
2014-09-02 17:28 ` Sergei Shtylyov
2014-09-02 17:45 ` Wolfram Sang
2014-09-02 18:10 ` Sergei Shtylyov [this message]
2014-09-04 18:05 ` Wolfram Sang
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=540607F9.4060802@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).