From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"Nuno Sá" <nuno.sa@analog.com>,
linux-iio@vger.kernel.org,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Lars-Peter Clausen" <lars@metafoo.de>
Subject: Re: [PATCH 0/2] ad5593r fix read protocol
Date: Fri, 16 Sep 2022 16:30:43 +0100 [thread overview]
Message-ID: <20220916163043.000059b3@huawei.com> (raw)
In-Reply-To: <d3d6ee8fdbbcf78a4b8b7f93bc8a417c811be18a.camel@gmail.com>
On Fri, 16 Sep 2022 08:05:29 +0200
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Thu, 2022-09-15 at 15:38 +0100, Jonathan Cameron wrote:
> > On Tue, 13 Sep 2022 09:34:11 +0200
> > Nuno Sá <nuno.sa@analog.com> wrote:
> >
> > > This patchset fixes the read protocol since it needs a STOP
> > > condition
> > > between address write and data read.
> > >
> > > The second change is trivial and only adds an i2c functionality
> > > check.
> >
> > Given we are late in the cycle, I've queued this up for the next
> > merge
> > window, with a stable tag for the first paatch so it'll get
> > backported
> > after the merge window.
> >
> >
>
> Alright. BTW, not sure If I already asked this but do you have any
> preference with regards to CCing stable? Should I have done it when
> submitting or do you prefer to handle it yourself?
Generally I prefer submitters to not tag for stable and let me make that
decision. Often I'll decide to not tag because I'm a little worried
about a fix and want it to be in mainline a little while before we
backport. I don't mind people sending explicit backport requests
though once it's soaked a bit.
Mind you, these days the scripts that check for possible fixes
often pick these up before I've gotten to sending a backport
request. Sometimes I send a note when that happens to ask for
it to soak longer, but mostly the delay is enough that I'm happy
the patch got enough soaking before that happens.
Occasionally I just forget to tag with stable. If that happens
then I'm fine with a request to pick it up being sent out once
it is upstream!
Jonathan
>
> - Nuno Sá
>
>
prev parent reply other threads:[~2022-09-16 15:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 7:34 [PATCH 0/2] ad5593r fix read protocol Nuno Sá
2022-09-13 7:34 ` [PATCH 1/2] iio: dac: ad5593r: Fix i2c read protocol requirements Nuno Sá
2022-09-13 7:34 ` [PATCH 2/2] iio: dac: ad5593r: add check for i2c functionality Nuno Sá
2022-09-15 14:38 ` [PATCH 0/2] ad5593r fix read protocol Jonathan Cameron
2022-09-16 6:05 ` Nuno Sá
2022-09-16 15:30 ` Jonathan Cameron [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=20220916163043.000059b3@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=noname.nuno@gmail.com \
--cc=nuno.sa@analog.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.