From: Wolfram Sang <wsa@the-dreams.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "kbuild test robot" <lkp@intel.com>,
kbuild-all@01.org, linux-i2c@vger.kernel.org,
"Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
linux-sh@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i2c: allow building emev2 without slave mode again
Date: Mon, 14 Dec 2015 14:52:06 +0100 [thread overview]
Message-ID: <20151214135206.GA1520@katana> (raw)
In-Reply-To: <15285750.UWXWiNJ6YU@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
> > What about not ifdeffing the inline function and keep the build error
> > whenever someone uses it without I2C_SLAVE being selected?
>
> The inline function is only added there for the case that I2C_SLAVE is
> disabled, so that would be pointless.
>
> However, what we could do is move the extern declaration outside of
> the #ifdef to make it always visible. The if(IS_ENABLED(CONFIG_I2C_SLAVE))
> check should then ensure that it never actually gets called, and we
> get a link error if some driver gets it wrong.
Yes, that's what I meant: move the whole function (as it was before your
patch) out of the CONFIG_I2C_SLAVE block. We should get a compiler error
even, because for !I2C_SLAVE, the client struct will not have the
slave_cb member.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@the-dreams.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] i2c: allow building emev2 without slave mode again
Date: Mon, 14 Dec 2015 13:52:06 +0000 [thread overview]
Message-ID: <20151214135206.GA1520@katana> (raw)
In-Reply-To: <15285750.UWXWiNJ6YU@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
> > What about not ifdeffing the inline function and keep the build error
> > whenever someone uses it without I2C_SLAVE being selected?
>
> The inline function is only added there for the case that I2C_SLAVE is
> disabled, so that would be pointless.
>
> However, what we could do is move the extern declaration outside of
> the #ifdef to make it always visible. The if(IS_ENABLED(CONFIG_I2C_SLAVE))
> check should then ensure that it never actually gets called, and we
> get a link error if some driver gets it wrong.
Yes, that's what I meant: move the whole function (as it was before your
patch) out of the CONFIG_I2C_SLAVE block. We should get a compiler error
even, because for !I2C_SLAVE, the client struct will not have the
slave_cb member.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: wsa@the-dreams.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i2c: allow building emev2 without slave mode again
Date: Mon, 14 Dec 2015 14:52:06 +0100 [thread overview]
Message-ID: <20151214135206.GA1520@katana> (raw)
In-Reply-To: <15285750.UWXWiNJ6YU@wuerfel>
> > What about not ifdeffing the inline function and keep the build error
> > whenever someone uses it without I2C_SLAVE being selected?
>
> The inline function is only added there for the case that I2C_SLAVE is
> disabled, so that would be pointless.
>
> However, what we could do is move the extern declaration outside of
> the #ifdef to make it always visible. The if(IS_ENABLED(CONFIG_I2C_SLAVE))
> check should then ensure that it never actually gets called, and we
> get a link error if some driver gets it wrong.
Yes, that's what I meant: move the whole function (as it was before your
patch) out of the CONFIG_I2C_SLAVE block. We should get a compiler error
even, because for !I2C_SLAVE, the client struct will not have the
slave_cb member.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151214/f70353ff/attachment-0001.sig>
next prev parent reply other threads:[~2015-12-14 13:52 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 13:14 [PATCH] i2c: allow building emev2 without slave mode again Arnd Bergmann
2015-12-10 13:14 ` Arnd Bergmann
2015-12-10 13:14 ` Arnd Bergmann
2015-12-10 13:34 ` Wolfram Sang
2015-12-10 13:34 ` Wolfram Sang
2015-12-10 13:34 ` Wolfram Sang
2015-12-10 13:51 ` Arnd Bergmann
2015-12-10 13:51 ` Arnd Bergmann
2015-12-10 13:51 ` Arnd Bergmann
2015-12-10 13:51 ` Arnd Bergmann
2015-12-10 14:54 ` kbuild test robot
2015-12-10 14:54 ` kbuild test robot
2015-12-10 14:54 ` kbuild test robot
2015-12-10 15:06 ` Arnd Bergmann
2015-12-10 15:06 ` Arnd Bergmann
2015-12-10 15:06 ` Arnd Bergmann
2015-12-10 15:06 ` Arnd Bergmann
2015-12-10 15:17 ` Wolfram Sang
2015-12-10 15:17 ` Wolfram Sang
2015-12-10 15:17 ` Wolfram Sang
2015-12-12 16:20 ` Wolfram Sang
2015-12-12 16:20 ` Wolfram Sang
2015-12-12 16:20 ` Wolfram Sang
2015-12-12 21:05 ` Arnd Bergmann
2015-12-12 21:05 ` Arnd Bergmann
2015-12-12 21:05 ` Arnd Bergmann
2015-12-12 21:05 ` Arnd Bergmann
2015-12-13 9:09 ` Wolfram Sang
2015-12-13 9:09 ` Wolfram Sang
2015-12-13 9:09 ` Wolfram Sang
2015-12-14 12:02 ` Arnd Bergmann
2015-12-14 12:02 ` Arnd Bergmann
2015-12-14 12:02 ` Arnd Bergmann
2015-12-14 13:52 ` Wolfram Sang [this message]
2015-12-14 13:52 ` Wolfram Sang
2015-12-14 13:52 ` Wolfram Sang
2015-12-14 22:27 ` Arnd Bergmann
2015-12-14 22:27 ` Arnd Bergmann
2015-12-14 22:27 ` Arnd Bergmann
2015-12-17 12:01 ` Wolfram Sang
2015-12-17 12:01 ` Wolfram Sang
2015-12-17 12:01 ` Wolfram Sang
2015-12-17 14:48 ` Arnd Bergmann
2015-12-17 14:48 ` Arnd Bergmann
2015-12-17 14:48 ` Arnd Bergmann
2015-12-17 19:40 ` Wolfram Sang
2015-12-17 19:40 ` Wolfram Sang
2015-12-17 19:40 ` Wolfram Sang
2015-12-17 19:57 ` Arnd Bergmann
2015-12-17 19:57 ` Arnd Bergmann
2015-12-17 19:57 ` Arnd Bergmann
2015-12-17 19:57 ` Arnd Bergmann
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=20151214135206.GA1520@katana \
--to=wsa@the-dreams.de \
--cc=arnd@arndb.de \
--cc=kbuild-all@01.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=lkp@intel.com \
--cc=niklas.soderlund+renesas@ragnatech.se \
/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.