From: Ladislav Michl <ladis@linux-mips.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: YueHaibing <yuehaibing@huawei.com>,
knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
denis.ciocca@st.com, rfontana@redhat.com, tglx@linutronix.de,
heiko.stuebner@bq.com, rjones@gateworks.com, drake@endlessm.com,
colin.king@canonical.com, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] iio: st_accel: Fix unused variable warning
Date: Sat, 2 Nov 2019 21:15:35 +0100 [thread overview]
Message-ID: <20191102201535.GA30346@lenoch> (raw)
In-Reply-To: <20191102140810.3d756294@archlinux>
On Sat, Nov 02, 2019 at 02:08:10PM +0000, Jonathan Cameron wrote:
> On Sat, 2 Nov 2019 11:41:25 +0100
> Ladislav Michl <ladis@linux-mips.org> wrote:
>
> > On Fri, Nov 01, 2019 at 09:47:41PM +0800, YueHaibing wrote:
> > > drivers/iio/accel/st_accel_core.c:1005:44: warning:
> > > mount_matrix_ext_info defined but not used [-Wunused-const-variable=]
> > >
> > > Move it to ifdef to mute this warning.
> > >
> > > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > > ---
> > > drivers/iio/accel/st_accel_core.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c
> > > index 2e37f8a..bba0717 100644
> > > --- a/drivers/iio/accel/st_accel_core.c
> > > +++ b/drivers/iio/accel/st_accel_core.c
> > > @@ -1002,10 +1002,12 @@ get_mount_matrix(const struct iio_dev *indio_dev,
> > > return adata->mount_matrix;
> > > }
> > >
> > > +#ifdef CONFIG_ACPI
> > > static const struct iio_chan_spec_ext_info mount_matrix_ext_info[] = {
> > > IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, get_mount_matrix),
> >
> > So now you do not get any warning for unused get_mount_matrix?
> > (Then it would make more sense to put all that stuff under one ifdef
> > and provide empty apply_acpi_orientation for non ACPI case)
>
> Does the __maybe_unused marking make this go away?
>
> I'd assume that the compiler will manage to drop this either way
> but I guess we should check that.
>
> ifdef magic is always harder to read and potentially fragile in the
> long run. Here we simply want to indicate that in some build
> configurations we might not use this.
This suggestion implies we'll get rid of CONFIG_ACPI completely, which
seems inapproriate looking at size of apply_acpi_orientation function.
And having both CONFIG_ACPI and __maybe_unused does not make much
sense. I had something like that in mind (+COMPILE_TEST perhaps):
diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c
index 2e37f8a6d8cf..0e7eac62d618 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -993,6 +993,7 @@ static const struct iio_trigger_ops st_accel_trigger_ops = {
#define ST_ACCEL_TRIGGER_OPS NULL
#endif
+#ifdef CONFIG_ACPI
static const struct iio_mount_matrix *
get_mount_matrix(const struct iio_dev *indio_dev,
const struct iio_chan_spec *chan)
@@ -1013,7 +1014,6 @@ static const struct iio_chan_spec_ext_info mount_matrix_ext_info[] = {
static int apply_acpi_orientation(struct iio_dev *indio_dev,
struct iio_chan_spec *channels)
{
-#ifdef CONFIG_ACPI
struct st_sensor_data *adata = iio_priv(indio_dev);
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
struct acpi_device *adev;
@@ -1141,10 +1141,14 @@ static int apply_acpi_orientation(struct iio_dev *indio_dev,
out:
kfree(buffer.pointer);
return ret;
-#else /* !CONFIG_ACPI */
+}
+#else
+static int apply_acpi_orientation(struct iio_dev *indio_dev,
+ struct iio_chan_spec *channels)
+{
return 0;
-#endif
}
+#endif
/*
* st_accel_get_settings() - get sensor settings from device name
> Thanks,
>
> Jonathan
>
>
> >
> > > { },
> > > };
> > > +#endif
> > >
> > > /* Read ST-specific _ONT orientation data from ACPI and generate an
> > > * appropriate mount matrix.
> > > --
> > > 2.7.4
> > >
next prev parent reply other threads:[~2019-11-02 20:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 13:47 [PATCH -next] iio: st_accel: Fix unused variable warning YueHaibing
2019-11-02 10:41 ` Ladislav Michl
2019-11-02 14:08 ` Jonathan Cameron
2019-11-02 20:15 ` Ladislav Michl [this message]
2019-11-03 11:01 ` Jonathan Cameron
2019-11-04 1:29 ` Yuehaibing
2019-11-09 11:50 ` Jonathan Cameron
2019-11-11 3:21 ` [PATCH v2 " YueHaibing
2019-11-16 14:58 ` Jonathan Cameron
2019-11-18 1:41 ` Yuehaibing
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=20191102201535.GA30346@lenoch \
--to=ladis@linux-mips.org \
--cc=colin.king@canonical.com \
--cc=denis.ciocca@st.com \
--cc=drake@endlessm.com \
--cc=heiko.stuebner@bq.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=rfontana@redhat.com \
--cc=rjones@gateworks.com \
--cc=tglx@linutronix.de \
--cc=yuehaibing@huawei.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.