Message ID | 20230310222857.315629-1-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 v21csp1396wrd; Fri, 10 Mar 2023 14:31:26 -0800 (PST) X-Google-Smtp-Source: AK7set9N5KuF8M9hVjGIfec7fWZfzOo0B/fHnLx7kN/u152pAyPczS8PQmi+gUElBfTsRl6jY0kV X-Received: by 2002:a05:6a20:1585:b0:cc:a93:2b81 with SMTP id h5-20020a056a20158500b000cc0a932b81mr28641337pzj.41.1678487486206; Fri, 10 Mar 2023 14:31:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678487486; cv=none; d=google.com; s=arc-20160816; b=nbgTaxz/4yccod+6xjQv5r50bLcHBstY7FG+9rLJqhqSUwuiTcu5giaQaxvGfiN0QG mmqhcK/VbvCQgzyLh9rn02OBnhSCfd/ZMpkKp4odLBcyQ42hV31IH+5KLE0w4E6hNV5Q kJ8RsNT08dWJ6HkLeB0s35fExlAqyvYHck/Mr/ozdDutX2jUVjRNVsaAigx90sSrVxpH CPNh3YINSeCA+QsupyLWKV/0HVFEw2Sw8NHonMZ6L2Pkjpeo3hXtyADAhCaeKBWU82II G/m1Ehh7s+pCdJUxmvpZN9CGeUffntnIimJXbHsLEmWTwJhCsIoWOHY5HVZrU+tMUnsK s2kQ== 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 :message-id:date:subject:to:from:dkim-signature; bh=60PuEIm35j5/lTNeJPhlkXRZcGNjzFmtFVCVem+hEDw=; b=CvXB5Vba48FvC2/zTSCJai0H/Wv6FXtqhYmn+Ll+FxrgtYiKIEoMf5MswQOJbltq1j 4xTqXt3WPGbDHvOwiPqV7UpfewF03dUNs2kEanfd8cAnWXPEFd7xs3N1M1CMkcv1yiEi eE7pyLth/40hg968ZOySIqweJlDU8sBo36/SYTjEGZHi6rS39HEcupa4UIP0FOj7Fd7w MJne57WZVNJFjKn8kVDetDCU+Ex5KuUDXtCezHb6GzalucpsRFRKA17s84rT6zdM+vPh izytUx2Gwr+DUkWKqSqPLU9F70sWS7jeDPoEtlQoOqxdzS/wNcyUBSENF4VHhNErSkaB /sAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LEfc0zEi; 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 q13-20020aa7960d000000b00593df8c5449si585013pfg.381.2023.03.10.14.31.11; Fri, 10 Mar 2023 14:31:26 -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=LEfc0zEi; 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 S231724AbjCJW3G (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Fri, 10 Mar 2023 17:29:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230232AbjCJW3D (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Mar 2023 17:29:03 -0500 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29356120491 for <linux-kernel@vger.kernel.org>; Fri, 10 Mar 2023 14:29:02 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id i34so26419614eda.7 for <linux-kernel@vger.kernel.org>; Fri, 10 Mar 2023 14:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678487340; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=60PuEIm35j5/lTNeJPhlkXRZcGNjzFmtFVCVem+hEDw=; b=LEfc0zEi+LQ5St5qp/OpSxRZTLSGwJrZ1Hg1Bjj2BqrW0jf1MDtYIRP0HBSYpqADEj WF3P0M3JfPUzD+0gnosaMbTzjvm7A21OxNXWw1cCY3V/EijHD8A57mAb+tmulhwrtNmZ /ey6MnBObA52rMXrEjca40rbROCtoOkxo00ygLa6tTa4IPsuDoy8BCLW4mXNNsI/mb3R JtMWGx0rRuUOJTylIlHrwVyQ7uG44r5J62FtVEjBEXguCGv+0Um5Q7oEhqDemugm9lCP n2LNdiqGW9semV4b/A988X57tQIYizAda0dcfvCxdBt2WybsTGqY6mRciCT0f6OPhsrB qMNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678487340; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=60PuEIm35j5/lTNeJPhlkXRZcGNjzFmtFVCVem+hEDw=; b=0qw/Cz4RSNII0l+n/W0mA3v9e5CG4jsBCHxPoaowpLOCVhidKUzqxojY59XLridMy2 PC+wwGqiIWgvZzkL02u3NsCUusfUryqauCCp6fzR5SimXIWZlq6a3MBcuxK/UO4qN2bm Q43UokPqplWhiColJOpcEOdzqDYleRVLREhIr9qp1Rvn2+pM/CpxPAAx7ww9DPhdVppo 6Yuuzz4vEo8CwR/AiyYkWRB4XVDaHbp0EDeBVQgmyuR1c0n6Xts2uVEZOSCMiuB5P+ak fSVbozSCRdvtRLShSQUcY7TCy9Wo/+EtJPrH/Stsevpf1xUS6xaLy6yd5c8mtNHb/lm3 dBwg== X-Gm-Message-State: AO0yUKUW1XuNtG2qdmSLXpSb96LWZh4oko3+8Jjs0T9tCQlroXW3wQyU mFeeR4LTdmww5MEqcQHQ4pwsUQ== X-Received: by 2002:a05:6402:1506:b0:4ac:c7b3:8c27 with SMTP id f6-20020a056402150600b004acc7b38c27mr25909175edw.28.1678487340674; Fri, 10 Mar 2023 14:29:00 -0800 (PST) Received: from krzk-bin.. ([2a02:810d:15c0:828:34:52e3:a77e:cac5]) by smtp.gmail.com with ESMTPSA id x101-20020a50baee000000b004aeeb476c5bsm525467ede.24.2023.03.10.14.28.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Mar 2023 14:29:00 -0800 (PST) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Mark Brown <broonie@kernel.org>, Kamal Dasu <kdasu.kdev@gmail.com>, Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, Neil Armstrong <neil.armstrong@linaro.org>, Kevin Hilman <khilman@baylibre.com>, Jerome Brunet <jbrunet@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Daniel Mack <daniel@zonque.org>, Haojian Zhuang <haojian.zhuang@gmail.com>, Robert Jarzmik <robert.jarzmik@free.fr>, Heiko Stuebner <heiko@sntech.de>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Andi Shyti <andi@etezian.org>, Alim Akhtar <alim.akhtar@samsung.com>, Stephen Boyd <sboyd@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [PATCH 01/16] spi: armada-3700: Drop of_match_ptr for ID table Date: Fri, 10 Mar 2023 23:28:42 +0100 Message-Id: <20230310222857.315629-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 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=ham 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?1760021694274378472?= X-GMAIL-MSGID: =?utf-8?q?1760021694274378472?= |
Series |
[01/16] spi: armada-3700: Drop of_match_ptr for ID table
|
|
Commit Message
Krzysztof Kozlowski
March 10, 2023, 10:28 p.m. UTC
The driver can match only via the DT table so the table should be always
used and the of_match_ptr does not have any sense (this also allows ACPI
matching via PRP0001, even though it is not relevant here).
drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/spi/spi-armada-3700.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote: > The driver can match only via the DT table so the table should be always > used and the of_match_ptr does not have any sense (this also allows ACPI > matching via PRP0001, even though it is not relevant here). > > drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=] It would be much better to fix of_match_ptr() and/or the module stuff that also references the match table here.
On Fri, 10 Mar 2023 23:28:42 +0100, Krzysztof Kozlowski wrote: > The driver can match only via the DT table so the table should be always > used and the of_match_ptr does not have any sense (this also allows ACPI > matching via PRP0001, even though it is not relevant here). > > drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=] > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [12/16] spi: pxa2xx: Mark OF related data as maybe unused commit: d94df25e8b9c8deefc5d7fcd344eb5d4bd41cf7b [13/16] spi: bcm-qspi: Mark OF related data as maybe unused commit: 6340fdf2e13c5f1ff3a9622f0cb3b8e9c3955a31 [14/16] spi: sh-msiof: Mark OF related data as maybe unused commit: d946b6b0ed01949b1a3856e03469361fc9168318 [15/16] spi: sc18is602: Mark OF related data as maybe unused commit: 833f43308234600e934e9c6fa70fd8b7eebc632b [16/16] spi: rspi: Mark OF related data as maybe unused commit: edfa970370a759c2c6a38b2884887937b1aea552 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On 13/03/2023 14:55, Mark Brown wrote: > On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote: >> The driver can match only via the DT table so the table should be always >> used and the of_match_ptr does not have any sense (this also allows ACPI >> matching via PRP0001, even though it is not relevant here). >> >> drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=] > > It would be much better to fix of_match_ptr() and/or the module stuff > that also references the match table here. Why? The recommendation is in general not to use of_match_ptr, because there are little benefits but it disables matching via PRP0001. Jonathan in parallel thread explicitly said of_match_ptr should disappear and he is not accepting any new code with it. And in general he is right. https://lore.kernel.org/all/20230311183534.1d0dfd64@jic23-huawei/ and earlier: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=444f5f854b35 Best regards, Krzysztof
On Mon, Mar 13, 2023 at 07:39:45PM +0100, Krzysztof Kozlowski wrote: > On 13/03/2023 14:55, Mark Brown wrote: > > On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote: > >> drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=] > > It would be much better to fix of_match_ptr() and/or the module stuff > > that also references the match table here. > Why? The recommendation is in general not to use of_match_ptr, because > there are little benefits but it disables matching via PRP0001. Jonathan > in parallel thread explicitly said of_match_ptr should disappear and he > is not accepting any new code with it. And in general he is right. If that's the case then why are you adding maybe unused annotations for half the drivers rather than removing their of_match_ptr() usages? There doesn't seem to be any logic here, it's just randomly making changes as far as I can tell. The PRP0001 stuff isn't an issue, of_match_ptr() can just be changed to do the right thing for CONFIG_ACPI. It doesn't buy us huge amounts but it also costs us very little and may be useful in future. When there's missing annotations it's not causing issues for practical configurations as far as I can tell, and if the macro were updated for CONFIG_ACPI it'd be even less of an issue.
On 13/03/2023 20:22, Mark Brown wrote: > On Mon, Mar 13, 2023 at 07:39:45PM +0100, Krzysztof Kozlowski wrote: >> On 13/03/2023 14:55, Mark Brown wrote: >>> On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote: > >>>> drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=] > >>> It would be much better to fix of_match_ptr() and/or the module stuff >>> that also references the match table here. > >> Why? The recommendation is in general not to use of_match_ptr, because >> there are little benefits but it disables matching via PRP0001. Jonathan >> in parallel thread explicitly said of_match_ptr should disappear and he >> is not accepting any new code with it. And in general he is right. > > If that's the case then why are you adding maybe unused annotations for > half the drivers rather than removing their of_match_ptr() usages? > There doesn't seem to be any logic here, it's just randomly making > changes as far as I can tell. These are not random but depend on whether OF is the only matching method or one of few. Although for IIO all of my patches would be dropping the of_match_ptr... For some cases in other patchsets I added __maybe_unused also because of_match_node(), when the table is not used in driver of_match_table. > > The PRP0001 stuff isn't an issue, of_match_ptr() can just be changed to > do the right thing for CONFIG_ACPI. That's actually interesting idea, kind of obvious so I wonder why it wasn't done like this in the first place in 886ca88be6b3 ("ACPI / bus: Respect PRP0001 when retrieving device match data"). Maybe not to populate OF device ID tables for the ACPI systems which do not care about PRP0001? > It doesn't buy us huge amounts but > it also costs us very little and may be useful in future. When there's > missing annotations it's not causing issues for practical configurations > as far as I can tell, and if the macro were updated for CONFIG_ACPI it'd > be even less of an issue. Best regards, Krzysztof
On Tue, Mar 14, 2023 at 07:44:04AM +0100, Krzysztof Kozlowski wrote: > On 13/03/2023 20:22, Mark Brown wrote: > > If that's the case then why are you adding maybe unused annotations for > > half the drivers rather than removing their of_match_ptr() usages? > > There doesn't seem to be any logic here, it's just randomly making > > changes as far as I can tell. > These are not random but depend on whether OF is the only matching > method or one of few. Although for IIO all of my patches would be > dropping the of_match_ptr... For some cases in other patchsets I added > __maybe_unused also because of_match_node(), when the table is not used > in driver of_match_table. This logic is both not apparent when looking at the patches and doesn't move us in any particular direction - I'd expect this stuff to be written the same way for all drivers, there's no reason for it to vary. That just adds complication, it's more random obscure rules people have to learn. > > The PRP0001 stuff isn't an issue, of_match_ptr() can just be changed to > > do the right thing for CONFIG_ACPI. > That's actually interesting idea, kind of obvious so I wonder why it > wasn't done like this in the first place in 886ca88be6b3 ("ACPI / bus: > Respect PRP0001 when retrieving device match data"). Maybe not to > populate OF device ID tables for the ACPI systems which do not care > about PRP0001? Or just it didn't occur to anyone at the time.
diff --git a/drivers/spi/spi-armada-3700.c b/drivers/spi/spi-armada-3700.c index 6a7e605f73bf..feb7371940bc 100644 --- a/drivers/spi/spi-armada-3700.c +++ b/drivers/spi/spi-armada-3700.c @@ -919,7 +919,7 @@ static void a3700_spi_remove(struct platform_device *pdev) static struct platform_driver a3700_spi_driver = { .driver = { .name = DRIVER_NAME, - .of_match_table = of_match_ptr(a3700_spi_dt_ids), + .of_match_table = a3700_spi_dt_ids, }, .probe = a3700_spi_probe, .remove_new = a3700_spi_remove,