From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Wolfram Sang <wsa@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>, <linux-iio@vger.kernel.org>,
<linux-i2c@vger.kernel.org>, Tom Rix <trix@redhat.com>,
Sean Nyekjaer <sean@geanix.com>
Subject: Re: [PATCH] i2c: core: Add stub for i2c_verify_client() if !CONFIG_I2C
Date: Thu, 3 Jun 2021 13:42:53 +0100 [thread overview]
Message-ID: <20210603134253.000012a8@Huawei.com> (raw)
In-Reply-To: <YLjDT1sxNm9ehjey@shikoro>
On Thu, 3 Jun 2021 13:55:59 +0200
Wolfram Sang <wsa@kernel.org> wrote:
> Hi Jonathan
>
> > Ok, so that is there because my assumption was that mostly like I'd take
> > this patch through IIO, in which case it's directly valid and necessary
> > for backport information purposes. I'm guessing this one is unlikely to
> > cause merge conflicts given how localized it is...
>
> I see. Makes sense.
>
> > You would do an immutable branch that I can pull into IIO. I'd really like
> > to avoid rebasing the IIO tree unless absolutely necessary as people are
> > working on top if it.
>
> Sure, let's avoid rebasing.
>
> > Doesn't work. There is a high chance the original patch will get ported
> > back to earlier kernels and there is no reference to let anyone know they
> > also need this one to avoid potential build issues on the stable kernel.
> >
> > So, if you want to take this through I2C, the path forwards would be.
> > 1) You take this one through I2C
> > 2) I apply the original fix (which #ifdefs the relevant code out in the
> > driver).
> > 3) Once (1) is in mainline next cycle, I can revert (2) on the basis
> > it is no longer necessary.
> >
> > I'm fine with doing it this way as it avoids any cross dependencies.
>
> The other solution is that you make an immutable branch for me? IIUC,
> this would be easiest? It would work for me.
Sure, I'll do that once we've agreed a v2
>
> > > > +#if IS_ENABLED(CONFIG_I2C)
> > >
> > > Hmm, can't we move this into an already existing IS_ENABLED block?
> >
> > There aren't any similar #if / #else blocks for CONFIG_I2C in i2c.h
> > so it seemed neater to just add one around this individual element
> > and not destroy the general organization of the file.
>
> Could be argued. I'd still prefer to add it at line 480 (5.13-rc3) with
> the #else branch added if you don't mind.
Sure, I'll move it.
Jonathan
>
> Thanks and kind regards,
>
> Wolfram
>
>
prev parent reply other threads:[~2021-06-03 12:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 17:44 [PATCH] i2c: core: Add stub for i2c_verify_client() if !CONFIG_I2C Jonathan Cameron
2021-05-27 5:38 ` Sean Nyekjaer
2021-05-27 20:23 ` Wolfram Sang
2021-06-03 11:24 ` Jonathan Cameron
2021-06-03 11:55 ` Wolfram Sang
2021-06-03 12:42 ` 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=20210603134253.000012a8@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=jic23@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=sean@geanix.com \
--cc=trix@redhat.com \
--cc=wsa@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;
as well as URLs for NNTP newsgroup(s).