Message ID | 20230311111457.251475-4-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp233593wrd; Sat, 11 Mar 2023 03:19:28 -0800 (PST) X-Google-Smtp-Source: AK7set9HLgVebJJmBRa33/d0krf5t+VHEsosxJ71WGVZkeY/NqQnAzIo+keB4DmuGYoJmPrt/mJ6 X-Received: by 2002:a05:6a21:6d81:b0:cb:2a12:c5d3 with SMTP id wl1-20020a056a216d8100b000cb2a12c5d3mr33023988pzb.10.1678533568184; Sat, 11 Mar 2023 03:19:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678533568; cv=none; d=google.com; s=arc-20160816; b=ifC7AM84jPufWTTstu1x3jueQtisd2igiJdaOul3d2OaHrezNyz8N4dxSOqu0M+ino NSbzeaOgva1GdqyxKKHM6hGoDe35hjR9k6BTNTLxixQc6ntPe2+wnQUekhMsLzLKo6Tf 51cj5qhvd5sy7onaEsPDd43jOBOAfJmeoOJrM0QWj2xzfNNDiQtK50DX1XtOu0ZJmZUs x1JgY7ZprG9nwI72FUj/ooGji7TowwQfTJCzFyZTXKQoh39XBNOQubo1wBwtAbsCDvOQ vyCOYUZi5lcLwPz76YfJqIFAcI3Ubz1vQGAuNNAcsNCw1Jvn0ctwnV23bt9dD6FGL/wD aa/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=QkQ93ugInkPpe3EPUwb7aGvfZMjL9q8ZpB0fY5f8jKo=; b=dbGOiBR4wHFXmMPBwk5ghnTxEokG+ZDVPWFiT7+s0HftOx8V2oeG3qIVIOSeQGQGSH 1UTS6yvHuLMnBuvHs1dAG6Sw/pjdNIsqKl6yfPcevYH7GfjkBiGrzTc2ZUlS9IK2OzyG 4n6tvJx5K2A3XX+KC6EipgZnQINkwjxJnKL3kXEUzymx8aBj9iqt0O0rPrnEPEui1Q+u S9Ki1xdQxjXE+1VYpLPeXPI5CxL4wesIX5S9TjCUaJ78t+XJMs1NsdI766gt4MZnSdzX BR5EwxhujZHzpAZ/EfswePJh3/1sry1tTO8ZpqS/y1VAi/QILMgla/7R7wkXr77dnSyy 4cZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XQHEU5fA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a23-20020aa794b7000000b005a8b16fd306si1764789pfl.340.2023.03.11.03.19.13; Sat, 11 Mar 2023 03:19:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XQHEU5fA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230326AbjCKLRe (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Sat, 11 Mar 2023 06:17:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230118AbjCKLQj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 11 Mar 2023 06:16:39 -0500 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7E514FAA7 for <linux-kernel@vger.kernel.org>; Sat, 11 Mar 2023 03:15:30 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id x3so30662248edb.10 for <linux-kernel@vger.kernel.org>; Sat, 11 Mar 2023 03:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678533304; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=QkQ93ugInkPpe3EPUwb7aGvfZMjL9q8ZpB0fY5f8jKo=; b=XQHEU5fAyON0vwZZc62gyPq4Sy+fd+RyFUbsV4vy1brKHUhuicHAAM3ykR8/lJxA5M FeQU2hHzfyYWr+daojlvdYgOSdiy85KzmPs2hATdnOO1LedgyLGlbbqmAZ4LmExBU4Zo vzqvIlza0evLN1j79EANAnwcvF0fCLHWDV20rc04T8OdnqTjSCTcr5baGT1yHqtVr1Ru tQ/wmkUCX24MvH3wssfFeQ0xdIRThGWUyEFI3MH68a9MtdWkNHyjVLjLgeQBjk/j3fOG kXWvgLEnNm9DYJV/2vHOgu/pXy4I0s9QwC72bTd0ncn4sMRpEu8+XWWjtTS9ldp/N/Fx 9VUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678533304; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QkQ93ugInkPpe3EPUwb7aGvfZMjL9q8ZpB0fY5f8jKo=; b=XOoi+9NOf772U1Y1waorxPqYPGYEbl9Any84v0DohjH48jkagrzHixHK2JnOBosgS8 o2Y9lHvI8wcRDjta/71bI3NITwOC9RChVUNAW1hUbiVbAeNcfz4eP3+WojAaJvo0Zl1p rtX7lN+B7RMGCcEYDDl64M0OyfzmBXjYw+CpSCAExvorzLHpzdO1r3e8v6qVyshKJag/ 42FbBsuJP95fYfPjGq+Vo35sxYZGQPJzQTJxJTqqyXp21J1NCUjt36GIorV1gNsfXKaf u5ieackKSoqeZo/RuEI8I4sBKvTgq8hoGwv7gbTn2z8eyUPns8dQ9x4WTC3NFQ0UIhKE wIBw== X-Gm-Message-State: AO0yUKWnmpgYhGwnLnPlDVTWlbOQPcMGSNknvI/Yu1cx5hgIu2p2lPwG PZDOZfZJ69fM+GaOHoqMSPQrdQ== X-Received: by 2002:a17:907:6f12:b0:8f3:9ee9:f1bc with SMTP id sy18-20020a1709076f1200b008f39ee9f1bcmr5368673ejc.13.1678533304460; Sat, 11 Mar 2023 03:15:04 -0800 (PST) Received: from krzk-bin.. ([2a02:810d:15c0:828:fa97:2d7c:bdd7:e1b]) by smtp.gmail.com with ESMTPSA id lc22-20020a170906dff600b00922b009fc79sm223427ejc.164.2023.03.11.03.15.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Mar 2023 03:15:04 -0800 (PST) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Marek Vasut <marek.vasut@gmail.com>, Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Michael Hennerich <Michael.Hennerich@analog.com>, Robert Eshleman <bobbyeshleman@gmail.com>, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Subject: [PATCH 4/4] iio: proximity: sx9500: Mark ACPI and OF related data as maybe unused Date: Sat, 11 Mar 2023 12:14:57 +0100 Message-Id: <20230311111457.251475-4-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230311111457.251475-1-krzysztof.kozlowski@linaro.org> References: <20230311111457.251475-1-krzysztof.kozlowski@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760070015078304450?= X-GMAIL-MSGID: =?utf-8?q?1760070015078304450?= |
Series |
[1/4] iio: adc: rcar-gyroadc: mark OF related data as maybe unused
|
|
Commit Message
Krzysztof Kozlowski
March 11, 2023, 11:14 a.m. UTC
The driver can be compile tested with !CONFIG_OF or !CONFIG_ACPI making
certain data unused:
drivers/iio/proximity/sx9500.c:1039:34: error: ‘sx9500_of_match’ defined but not used [-Werror=unused-const-variable=]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/iio/proximity/sx9500.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Sat, 11 Mar 2023 12:14:57 +0100 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > The driver can be compile tested with !CONFIG_OF or !CONFIG_ACPI making > certain data unused: > > drivers/iio/proximity/sx9500.c:1039:34: error: ‘sx9500_of_match’ defined but not used [-Werror=unused-const-variable=] > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Hi Krysztof Thanks for looking at these warnings. Drop the protection macros instead. The tables are trivial in size and the of_match_ptr() breaks some ways this driver can be used. ACPI_PTR() isn't as bad, but is pretty much pointless given this size of the array. Jonathan > --- > drivers/iio/proximity/sx9500.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c > index 8794e75e5bf9..840db1953998 100644 > --- a/drivers/iio/proximity/sx9500.c > +++ b/drivers/iio/proximity/sx9500.c > @@ -1036,13 +1036,13 @@ static const struct acpi_device_id sx9500_acpi_match[] = { > }; > MODULE_DEVICE_TABLE(acpi, sx9500_acpi_match); > > -static const struct of_device_id sx9500_of_match[] = { > +static const struct of_device_id sx9500_of_match[] __maybe_unused = { > { .compatible = "semtech,sx9500", }, > { } > }; > MODULE_DEVICE_TABLE(of, sx9500_of_match); > > -static const struct i2c_device_id sx9500_id[] = { > +static const struct i2c_device_id sx9500_id[] __maybe_unused = { > {"sx9500", 0}, > { }, > };
On 11/03/2023 13:28, Jonathan Cameron wrote: > On Sat, 11 Mar 2023 12:14:57 +0100 > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > >> The driver can be compile tested with !CONFIG_OF or !CONFIG_ACPI making >> certain data unused: >> >> drivers/iio/proximity/sx9500.c:1039:34: error: ‘sx9500_of_match’ defined but not used [-Werror=unused-const-variable=] >> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > Hi Krysztof > > Thanks for looking at these warnings. > > Drop the protection macros instead. The tables are trivial in size and > the of_match_ptr() breaks some ways this driver can be used. > ACPI_PTR() isn't as bad, but is pretty much pointless given this size of > the array. > For ACPI platform, ACPI table is used, so nothing for PRP0001. For OF platform, OF table is used. What usage exactly is broken here? What ways? Best regards, Krzysztof
On Sat, 11 Mar 2023 13:30:01 +0100 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 11/03/2023 13:28, Jonathan Cameron wrote: > > On Sat, 11 Mar 2023 12:14:57 +0100 > > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > > >> The driver can be compile tested with !CONFIG_OF or !CONFIG_ACPI making > >> certain data unused: > >> > >> drivers/iio/proximity/sx9500.c:1039:34: error: ‘sx9500_of_match’ defined but not used [-Werror=unused-const-variable=] > >> > >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > Hi Krysztof > > > > Thanks for looking at these warnings. > > > > Drop the protection macros instead. The tables are trivial in size and > > the of_match_ptr() breaks some ways this driver can be used. > > ACPI_PTR() isn't as bad, but is pretty much pointless given this size of > > the array. > > > > For ACPI platform, ACPI table is used, so nothing for PRP0001. For OF > platform, OF table is used. So you would think, but nope.. That's not how it works (I was surprised when I came across this the first time too) PRP0001 is magic and requires no specific support in an individual driver beyond not using that of_match_ptr() macro! https://elixir.bootlin.com/linux/latest/source/drivers/acpi/bus.c#L754 Docs here https://elixir.bootlin.com/linux/latest/source/Documentation/firmware-guide/acpi/enumeration.rst#L450 > > What usage exactly is broken here? What ways? > > Best regards, > Krzysztof >
On 11/03/2023 19:44, Jonathan Cameron wrote: > On Sat, 11 Mar 2023 13:30:01 +0100 > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > >> On 11/03/2023 13:28, Jonathan Cameron wrote: >>> On Sat, 11 Mar 2023 12:14:57 +0100 >>> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: >>> >>>> The driver can be compile tested with !CONFIG_OF or !CONFIG_ACPI making >>>> certain data unused: >>>> >>>> drivers/iio/proximity/sx9500.c:1039:34: error: ‘sx9500_of_match’ defined but not used [-Werror=unused-const-variable=] >>>> >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>> >>> Hi Krysztof >>> >>> Thanks for looking at these warnings. >>> >>> Drop the protection macros instead. The tables are trivial in size and >>> the of_match_ptr() breaks some ways this driver can be used. >>> ACPI_PTR() isn't as bad, but is pretty much pointless given this size of >>> the array. >>> >> >> For ACPI platform, ACPI table is used, so nothing for PRP0001. For OF >> platform, OF table is used. > > So you would think, but nope.. That's not how it works (I was surprised > when I came across this the first time too) > > PRP0001 is magic and requires no specific support in an individual > driver beyond not using that of_match_ptr() macro! I know, we talk about ACPI table. > > https://elixir.bootlin.com/linux/latest/source/drivers/acpi/bus.c#L754 > Docs here > https://elixir.bootlin.com/linux/latest/source/Documentation/firmware-guide/acpi/enumeration.rst#L450 The code is compile when CONFIG_ACPI is defined, right? Then you have ACPI table, so what for ACPI platform is missing? ACPI platform has ACPI table. Best regards, Krzysztof
On Sun, 12 Mar 2023 11:17:05 +0100 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 11/03/2023 19:44, Jonathan Cameron wrote: > > On Sat, 11 Mar 2023 13:30:01 +0100 > > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > > >> On 11/03/2023 13:28, Jonathan Cameron wrote: > >>> On Sat, 11 Mar 2023 12:14:57 +0100 > >>> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > >>> > >>>> The driver can be compile tested with !CONFIG_OF or !CONFIG_ACPI making > >>>> certain data unused: > >>>> > >>>> drivers/iio/proximity/sx9500.c:1039:34: error: ‘sx9500_of_match’ defined but not used [-Werror=unused-const-variable=] > >>>> > >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >>> > >>> Hi Krysztof > >>> > >>> Thanks for looking at these warnings. > >>> > >>> Drop the protection macros instead. The tables are trivial in size and > >>> the of_match_ptr() breaks some ways this driver can be used. > >>> ACPI_PTR() isn't as bad, but is pretty much pointless given this size of > >>> the array. > >>> > >> > >> For ACPI platform, ACPI table is used, so nothing for PRP0001. For OF > >> platform, OF table is used. > > > > So you would think, but nope.. That's not how it works (I was surprised > > when I came across this the first time too) > > > > PRP0001 is magic and requires no specific support in an individual > > driver beyond not using that of_match_ptr() macro! > > I know, we talk about ACPI table. I'm not sure I follow. I thought by ACPI table you meant the acpi_device_id table pointed to by acpi_match_table in struct device_driver. That one is not needed for PRP0001. It is irrelevant if there is one or not. Maybe the confusion is that you think the presence of an acpi_match table means we don't also check PRP0001? As you can see here https://elixir.bootlin.com/linux/latest/source/drivers/acpi/bus.c#L886 it is checked in all cases. If you meant the DSDT table being provide by the firmware I don't see the relevance to this discussion. > > > > > https://elixir.bootlin.com/linux/latest/source/drivers/acpi/bus.c#L754 > > Docs here > > https://elixir.bootlin.com/linux/latest/source/Documentation/firmware-guide/acpi/enumeration.rst#L450 > > The code is compile when CONFIG_ACPI is defined, right? Then you have > ACPI table, so what for ACPI platform is missing? ACPI platform has ACPI > table. I don't follow. A given ACPI platform may provide in DSDT one of two choices to bind to this driver. Either it provides an entry from the acpi_device_id table, or it must use PRP0001 and a compatible entry from the of_device_id table. That only works if of_match_ptr() is not used. As a side note, both the IDs in the ACPI match table are not valid IDs for use in DSDT. We are supporting them only because they have been used on shipping devices. Semtech does have a PNP ID of STH but that's not the one used. Anyhow, to be clear. For IIO drivers, don't use of_match_ptr() or ACPI_PTR(). There are some legacy cases that we haven't cleaned up yet, but I'm not taking patches that add any new ones without a very very strong argument in favour and so far no one has successfully made one. Jonathan > > Best regards, > Krzysztof >
On 12/03/2023 15:14, Jonathan Cameron wrote: > On Sun, 12 Mar 2023 11:17:05 +0100 > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > >> On 11/03/2023 19:44, Jonathan Cameron wrote: >>> On Sat, 11 Mar 2023 13:30:01 +0100 >>> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: >>> >>>> On 11/03/2023 13:28, Jonathan Cameron wrote: >>>>> On Sat, 11 Mar 2023 12:14:57 +0100 >>>>> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: >>>>> >>>>>> The driver can be compile tested with !CONFIG_OF or !CONFIG_ACPI making >>>>>> certain data unused: >>>>>> >>>>>> drivers/iio/proximity/sx9500.c:1039:34: error: ‘sx9500_of_match’ defined but not used [-Werror=unused-const-variable=] >>>>>> >>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>>> >>>>> Hi Krysztof >>>>> >>>>> Thanks for looking at these warnings. >>>>> >>>>> Drop the protection macros instead. The tables are trivial in size and >>>>> the of_match_ptr() breaks some ways this driver can be used. >>>>> ACPI_PTR() isn't as bad, but is pretty much pointless given this size of >>>>> the array. >>>>> >>>> >>>> For ACPI platform, ACPI table is used, so nothing for PRP0001. For OF >>>> platform, OF table is used. >>> >>> So you would think, but nope.. That's not how it works (I was surprised >>> when I came across this the first time too) >>> >>> PRP0001 is magic and requires no specific support in an individual >>> driver beyond not using that of_match_ptr() macro! >> >> I know, we talk about ACPI table. > > I'm not sure I follow. I thought by ACPI table you meant the acpi_device_id > table pointed to by acpi_match_table in struct device_driver. > > That one is not needed for PRP0001. It is irrelevant if there is one or not. > > Maybe the confusion is that you think the presence of an acpi_match table means > we don't also check PRP0001? As you can see here > https://elixir.bootlin.com/linux/latest/source/drivers/acpi/bus.c#L886 > it is checked in all cases. > > If you meant the DSDT table being provide by the firmware I don't see the relevance > to this discussion. > >> >>> >>> https://elixir.bootlin.com/linux/latest/source/drivers/acpi/bus.c#L754 >>> Docs here >>> https://elixir.bootlin.com/linux/latest/source/Documentation/firmware-guide/acpi/enumeration.rst#L450 >> >> The code is compile when CONFIG_ACPI is defined, right? Then you have >> ACPI table, so what for ACPI platform is missing? ACPI platform has ACPI >> table. > > I don't follow. A given ACPI platform may provide in DSDT one of two choices > to bind to this driver. OK, I understand your point. I assumed we do not care at all about PRP0001 if ACPI is enabled, because then we simply use ACPI table. But indeed they might for example be not in sync... > > Either it provides an entry from the acpi_device_id table, or it must > use PRP0001 and a compatible entry from the of_device_id table. That only works > if of_match_ptr() is not used. > > As a side note, both the IDs in the ACPI match table are not valid IDs for use > in DSDT. We are supporting them only because they have been used on shipping devices. > Semtech does have a PNP ID of STH but that's not the one used. > > Anyhow, to be clear. For IIO drivers, don't use of_match_ptr() > or ACPI_PTR(). There are some legacy cases that we haven't cleaned up > yet, but I'm not taking patches that add any new ones without a very very > strong argument in favour and so far no one has successfully made one. Best regards, Krzysztof
diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c index 8794e75e5bf9..840db1953998 100644 --- a/drivers/iio/proximity/sx9500.c +++ b/drivers/iio/proximity/sx9500.c @@ -1036,13 +1036,13 @@ static const struct acpi_device_id sx9500_acpi_match[] = { }; MODULE_DEVICE_TABLE(acpi, sx9500_acpi_match); -static const struct of_device_id sx9500_of_match[] = { +static const struct of_device_id sx9500_of_match[] __maybe_unused = { { .compatible = "semtech,sx9500", }, { } }; MODULE_DEVICE_TABLE(of, sx9500_of_match); -static const struct i2c_device_id sx9500_id[] = { +static const struct i2c_device_id sx9500_id[] __maybe_unused = { {"sx9500", 0}, { }, };