All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	"kbuild test robot" <lkp@intel.com>,
	linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	kbuild-all@01.org
Subject: Re: [PATCH] i2c: allow building emev2 without slave mode again
Date: Thu, 17 Dec 2015 20:57:04 +0100	[thread overview]
Message-ID: <7990730.tNeXHUrIig@wuerfel> (raw)
In-Reply-To: <20151217194016.GD1530@katana>

On Thursday 17 December 2015 20:40:17 Wolfram Sang wrote:
> > > My conclusion for now is:
> > > 
> > > There needs something to be done surely, but currently I don't have the
> > > bandwidth to do it or even play around with it. I am not fully happy
> > > with your patches as well because __maybe_unused has some kind of "last
> > > resort" feeling to me.
> > 
> > I generally like __maybe_unused, but it's a matter of personal preference.
> > We could avoid the __maybe_unused if the reg_slave/unreg_slave callback
> > pointers are always available in struct i2c_algorithm.
> 
> Yes, I was thinking in this direction, looking at how PM does it. Needs
> some playing around, though.

I think PM gets it slightly wrong, the way you have to use #ifdef leads
to subtle bugs all the time, and I actually have a patch that converts
a few dozen drivers to use __maybe_unused to shut up build warnings and
errors.

What you can do though is to use a reference like

#define __i2c_slave_ptr(x) (IS_ENABLED(CONFIG_I2C_SLAVE) ? (x) : NULL)

	...
	.reg_slave = __i2c_slave_ptr(em_i2c_reg_slave),
	.unreg_slave = __i2c_slave_ptr(em_i2c_unreg_slave),
	...

This has the same effect as the __maybe_unused annotation.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] i2c: allow building emev2 without slave mode again
Date: Thu, 17 Dec 2015 19:57:04 +0000	[thread overview]
Message-ID: <7990730.tNeXHUrIig@wuerfel> (raw)
In-Reply-To: <20151217194016.GD1530@katana>

On Thursday 17 December 2015 20:40:17 Wolfram Sang wrote:
> > > My conclusion for now is:
> > > 
> > > There needs something to be done surely, but currently I don't have the
> > > bandwidth to do it or even play around with it. I am not fully happy
> > > with your patches as well because __maybe_unused has some kind of "last
> > > resort" feeling to me.
> > 
> > I generally like __maybe_unused, but it's a matter of personal preference.
> > We could avoid the __maybe_unused if the reg_slave/unreg_slave callback
> > pointers are always available in struct i2c_algorithm.
> 
> Yes, I was thinking in this direction, looking at how PM does it. Needs
> some playing around, though.

I think PM gets it slightly wrong, the way you have to use #ifdef leads
to subtle bugs all the time, and I actually have a patch that converts
a few dozen drivers to use __maybe_unused to shut up build warnings and
errors.

What you can do though is to use a reference like

#define __i2c_slave_ptr(x) (IS_ENABLED(CONFIG_I2C_SLAVE) ? (x) : NULL)

	...
	.reg_slave = __i2c_slave_ptr(em_i2c_reg_slave),
	.unreg_slave = __i2c_slave_ptr(em_i2c_unreg_slave),
	...

This has the same effect as the __maybe_unused annotation.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i2c: allow building emev2 without slave mode again
Date: Thu, 17 Dec 2015 20:57:04 +0100	[thread overview]
Message-ID: <7990730.tNeXHUrIig@wuerfel> (raw)
In-Reply-To: <20151217194016.GD1530@katana>

On Thursday 17 December 2015 20:40:17 Wolfram Sang wrote:
> > > My conclusion for now is:
> > > 
> > > There needs something to be done surely, but currently I don't have the
> > > bandwidth to do it or even play around with it. I am not fully happy
> > > with your patches as well because __maybe_unused has some kind of "last
> > > resort" feeling to me.
> > 
> > I generally like __maybe_unused, but it's a matter of personal preference.
> > We could avoid the __maybe_unused if the reg_slave/unreg_slave callback
> > pointers are always available in struct i2c_algorithm.
> 
> Yes, I was thinking in this direction, looking at how PM does it. Needs
> some playing around, though.

I think PM gets it slightly wrong, the way you have to use #ifdef leads
to subtle bugs all the time, and I actually have a patch that converts
a few dozen drivers to use __maybe_unused to shut up build warnings and
errors.

What you can do though is to use a reference like

#define __i2c_slave_ptr(x) (IS_ENABLED(CONFIG_I2C_SLAVE) ? (x) : NULL)

	...
	.reg_slave = __i2c_slave_ptr(em_i2c_reg_slave),
	.unreg_slave = __i2c_slave_ptr(em_i2c_unreg_slave),
	...

This has the same effect as the __maybe_unused annotation.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Wolfram Sang <wsa@the-dreams.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: Thu, 17 Dec 2015 20:57:04 +0100	[thread overview]
Message-ID: <7990730.tNeXHUrIig@wuerfel> (raw)
In-Reply-To: <20151217194016.GD1530@katana>

On Thursday 17 December 2015 20:40:17 Wolfram Sang wrote:
> > > My conclusion for now is:
> > > 
> > > There needs something to be done surely, but currently I don't have the
> > > bandwidth to do it or even play around with it. I am not fully happy
> > > with your patches as well because __maybe_unused has some kind of "last
> > > resort" feeling to me.
> > 
> > I generally like __maybe_unused, but it's a matter of personal preference.
> > We could avoid the __maybe_unused if the reg_slave/unreg_slave callback
> > pointers are always available in struct i2c_algorithm.
> 
> Yes, I was thinking in this direction, looking at how PM does it. Needs
> some playing around, though.

I think PM gets it slightly wrong, the way you have to use #ifdef leads
to subtle bugs all the time, and I actually have a patch that converts
a few dozen drivers to use __maybe_unused to shut up build warnings and
errors.

What you can do though is to use a reference like

#define __i2c_slave_ptr(x) (IS_ENABLED(CONFIG_I2C_SLAVE) ? (x) : NULL)

	...
	.reg_slave = __i2c_slave_ptr(em_i2c_reg_slave),
	.unreg_slave = __i2c_slave_ptr(em_i2c_unreg_slave),
	...

This has the same effect as the __maybe_unused annotation.

	Arnd

  reply	other threads:[~2015-12-17 19:57 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
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 [this message]
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=7990730.tNeXHUrIig@wuerfel \
    --to=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 \
    --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.