Message ID | 20230310223027.315954-2-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 v21csp3647wrd; Fri, 10 Mar 2023 14:37:24 -0800 (PST) X-Google-Smtp-Source: AK7set+YMe+2wU5ECfbxghmhMC2QQbLAvzHTM7w/QVRWJadNlQ0/vfAHzoNnYJWb0i9/23Gcg0I+ X-Received: by 2002:a05:6a21:338d:b0:cb:c4de:a20 with SMTP id yy13-20020a056a21338d00b000cbc4de0a20mr33025786pzb.55.1678487843923; Fri, 10 Mar 2023 14:37:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678487843; cv=none; d=google.com; s=arc-20160816; b=Fk96YV9amazgsOq56IsoipwhLeAAOBmKL8TdHomGxYHsuQXHaYJ8iYHzcvyCHJkIby PIhjTd24Ejro1wYyPthxTC48fbGg/oiuAa2ZYTdPu9FGFYS9jSORFqS3U5VOC6wXvNzR hudqlxrnXv6yJbiCTR3RUm/fwaOTtpvogqR3J1o/rzPEWzvFTdDyF0tANSS8ZEq4xiwT bR3Dhvyam/1hmC6j6Rf7A2cJxtLQm5Z4c5xMTdwsstgz5wvXPoViHJGIZRDH9Gw2FaSv OkweP4DKmoI2piJK3j0m1ZnLJD6aGXz8Zvd46oFfOZuQeO211C6Njfqv/jbxxYZrn8nT n04w== 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=268bZ1TBueiybyhkcpErcA+C9yqfqKZytn9F0qROzMs=; b=fWL961Ih207Q+Uh4MJjvW/t5nLepDyIF8wGM49VCHugKmOaHH7/hSxdLlx/9J64fds EPoEqYUZgj7bsyaf/PQ4r1Xzs/pUpgjnAu4zkf8C1/r6Ch8iGYPPmmyItlAJKtV48ikT sckyw8D91RN4PaQ0dGEhqRB9TErNB8vMAkxlJ5yHgt38u6e2OcDe/jG7vL1t5IMxraTq YGX7Pl0ZT8hAh2LkNWS6/mEn7VeljMlDGV2QSdGB+6cZwWJI4O+g+/SwttyJ+Z3OH6HW E05RYQ9ZrxE5aF6LR49xDBP44viFmg9YGPKFAzomVrZhg0k7RXzifUxpC5HOqllnGm1x q24Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=WbmdjplX; 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 g5-20020a635205000000b005074d6754e3si797144pgb.255.2023.03.10.14.37.08; Fri, 10 Mar 2023 14:37:23 -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=WbmdjplX; 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 S232116AbjCJWca (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Fri, 10 Mar 2023 17:32:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232017AbjCJWcC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Mar 2023 17:32:02 -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 5882D148B65 for <linux-kernel@vger.kernel.org>; Fri, 10 Mar 2023 14:30:38 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id o12so26464625edb.9 for <linux-kernel@vger.kernel.org>; Fri, 10 Mar 2023 14:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678487430; 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=268bZ1TBueiybyhkcpErcA+C9yqfqKZytn9F0qROzMs=; b=WbmdjplXq98Xewg+y118GdddG0T2GZpR2Lv2/E3ifF6exl4IYQoLFQYyyIwWCZ4GLt NTNzbH8KnPh15cZHw6H6IVh5m5DxVU0eX787ZT9b2lCpn7vRtwZDMn/StenHYkx2lhEd aA+MSGLK6E8xpijpR590AwNAaT+xiFblPrDnPajvvjz+7yNfYb7YmfKf5p391xtV75iF FluPgocmtnvggbxFVGHtgUUeUAuY5jm0BqAymCoYnUMuW+HzzEML7aR2B7AtTzTOwXIx WpsN/IX7ihA+QtjwDwgoIkeDLgwFSGGhtqcfAJlhGXn3mz9dfZ/Sl/UVB2h20Qv3HN1y fibw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678487430; 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=268bZ1TBueiybyhkcpErcA+C9yqfqKZytn9F0qROzMs=; b=u35Lynbbs1PiZCsiW3GGIl103NA2LVp+9pOMYRppwpkRK76nYQHc60zOMjJDtxYHGK v1WzW5ELIBj3KN4HCoTaXa+q8tSaQk8PRPvSlfGx6xWxJKDAPBYMhCAcCSFFTep4AWdj x69VZo2AJbl/4iO4siqbhjVYI0sOS4hjrcHREpxu8Ci+WEfDPicZKV/ArOMctvGfhGNt 53bjqbhUOxkhFN+oUMxknZOUi4QGuNBrAs5/DhjiGJmhSlr4Q8Ie76TtGlmXRkoqfq6W QY6ybmKKPM9kfLEWF1EjeJKoEiyPvghyfesMSDcvDWqjUI16PTaexV2DdD72R2xf3Hr1 qvkw== X-Gm-Message-State: AO0yUKWJwOc3N9ivJC3mA+2xAnfc6w2X9dQi5JwPl2KwOkjepvhxi1ls 7uIyMK5ePOIS6nW8Z37e7MoIYQ== X-Received: by 2002:a17:907:6ea6:b0:8b1:7dea:cc40 with SMTP id sh38-20020a1709076ea600b008b17deacc40mr33181747ejc.9.1678487430083; Fri, 10 Mar 2023 14:30:30 -0800 (PST) Received: from krzk-bin.. ([2a02:810d:15c0:828:34:52e3:a77e:cac5]) by smtp.gmail.com with ESMTPSA id l23-20020a170906939700b008c5075f5331sm360279ejx.165.2023.03.10.14.30.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Mar 2023 14:30:29 -0800 (PST) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Herbert Xu <herbert@gondor.apana.org.au>, "David S. Miller" <davem@davemloft.net>, Nicolas Ferre <nicolas.ferre@microchip.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Claudiu Beznea <claudiu.beznea@microchip.com>, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Subject: [PATCH 2/2] crypto - img-hash: Drop of_match_ptr for ID table Date: Fri, 10 Mar 2023 23:30:27 +0100 Message-Id: <20230310223027.315954-2-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230310223027.315954-1-krzysztof.kozlowski@linaro.org> References: <20230310223027.315954-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=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?1760022069866314907?= X-GMAIL-MSGID: =?utf-8?q?1760022069866314907?= |
Series |
[1/2] usb: typec: hd3ss3220: Drop of_match_ptr for ID table
|
|
Commit Message
Krzysztof Kozlowski
March 10, 2023, 10:30 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/crypto/img-hash.c:930:34: error: ‘img_hash_match’ defined but not used [-Werror=unused-const-variable=]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/crypto/img-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Fri, Mar 10, 2023 at 11:30:27PM +0100, Krzysztof Kozlowski wrote: > > diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c > index fe93d19e3044..4e9a6660d791 100644 > --- a/drivers/crypto/img-hash.c > +++ b/drivers/crypto/img-hash.c > @@ -1106,7 +1106,7 @@ static struct platform_driver img_hash_driver = { > .driver = { > .name = "img-hash-accelerator", > .pm = &img_hash_pm_ops, > - .of_match_table = of_match_ptr(img_hash_match), > + .of_match_table = img_hash_match, I think we should keep this because this driver doesn't explicitly depend on OF. Sure of_match_table is unconditionally defined but I'd call that a bug instead of a feature :) However, I would take this if you resend it with a Kconfig update to add an explicit dependency on OF. Thanks,
On 17/03/2023 04:04, Herbert Xu wrote: > On Fri, Mar 10, 2023 at 11:30:27PM +0100, Krzysztof Kozlowski wrote: >> >> diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c >> index fe93d19e3044..4e9a6660d791 100644 >> --- a/drivers/crypto/img-hash.c >> +++ b/drivers/crypto/img-hash.c >> @@ -1106,7 +1106,7 @@ static struct platform_driver img_hash_driver = { >> .driver = { >> .name = "img-hash-accelerator", >> .pm = &img_hash_pm_ops, >> - .of_match_table = of_match_ptr(img_hash_match), >> + .of_match_table = img_hash_match, > > I think we should keep this because this driver doesn't explicitly > depend on OF. Sure of_match_table is unconditionally defined but > I'd call that a bug instead of a feature :) The missing dependency on OF is not a problem. The OF code is prepare and will work fine if the driver is built with !OF. The point is that with !OF after dropping of_match_ptr(), the driver could match via ACPI (PRP0001). If we make it depending on OF, the driver won't be able to use it, unless kernel is built with OF which is unlikely for ACPI systems. > > However, I would take this if you resend it with a Kconfig update > to add an explicit dependency on OF. > > Thanks, Best regards, Krzysztof
On Fri, Mar 17, 2023 at 09:12:05AM +0100, Krzysztof Kozlowski wrote: > > The missing dependency on OF is not a problem. The OF code is prepare > and will work fine if the driver is built with !OF. The point is that > with !OF after dropping of_match_ptr(), the driver could match via ACPI > (PRP0001). If we make it depending on OF, the driver won't be able to > use it, unless kernel is built with OF which is unlikely for ACPI systems. I know it works now, but what I'm saying is that if struct device_driver actually had of_match_table as conditional on OF, which ideally it should, then removing of_match_ptr will break the build. I know that it's currently unconditionally defined, but that's just wasting memory on non-OF machines such as x86. So either this driver is OF-only, in which case you can drop the of_match_ptr but must add a dependency on OF. Or it's not OF-only, in which case you should use of_match_ptr. Cheers,
On 17/03/2023 09:30, Herbert Xu wrote: > On Fri, Mar 17, 2023 at 09:12:05AM +0100, Krzysztof Kozlowski wrote: >> >> The missing dependency on OF is not a problem. The OF code is prepare >> and will work fine if the driver is built with !OF. The point is that >> with !OF after dropping of_match_ptr(), the driver could match via ACPI >> (PRP0001). If we make it depending on OF, the driver won't be able to >> use it, unless kernel is built with OF which is unlikely for ACPI systems. > > I know it works now, but what I'm saying is that if struct device_driver > actually had of_match_table as conditional on OF, which ideally it > should, then removing of_match_ptr will break the build. > > I know that it's currently unconditionally defined, but that's > just wasting memory on non-OF machines such as x86. That's not true. There is no waste because having it on x86 allows to match via ACPI PRP0001. It's on purpose there. > So either this driver is OF-only, in which case you can drop > the of_match_ptr but must add a dependency on OF. Or it's not > OF-only, in which case you should use of_match_ptr. There are OF-drivers used on ACPI and x86/arm64. The true question is whether this device will be ever used on ACPI via PRP0001, but you are not referring to this? Best regards, Krzysztof
On Fri, Mar 17, 2023 at 10:01:44AM +0100, Krzysztof Kozlowski wrote: > > That's not true. There is no waste because having it on x86 allows to > match via ACPI PRP0001. It's on purpose there. Alright how about this, I don't have any OF devices on my machine yet this structure is still taking up the extra memory for every single device driver. This is wrong. > There are OF-drivers used on ACPI and x86/arm64. Well then they should be selecting OF and everyone will be happy. Cheers,
On 17/03/2023 10:15, Herbert Xu wrote: > On Fri, Mar 17, 2023 at 10:01:44AM +0100, Krzysztof Kozlowski wrote: >> >> That's not true. There is no waste because having it on x86 allows to >> match via ACPI PRP0001. It's on purpose there. > > Alright how about this, I don't have any OF devices on my machine > yet this structure is still taking up the extra memory for every > single device driver. This is wrong. > >> There are OF-drivers used on ACPI and x86/arm64. > > Well then they should be selecting OF and everyone will be happy. OK, I will change it. It's a bit tiring to discuss the same concept with different maintainers and each time receive different point of view or each time need to convince that the other way is preferred. I already had such talks with Mark, so it is just easier change patch. Also, I tend to keep forgetting all the arguments. :) Let me just share also other maintainer's point of view: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e62470652fa https://lore.kernel.org/all/20230311183534.1d0dfd64@jic23-huawei/ Anyway, I appreciate your feedback and thank you for picking up the first patch. I'll rework this one. Have a nice day! Best regards, Krzysztof
On Fri, 17 Mar 2023 at 10:16, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Fri, Mar 17, 2023 at 10:01:44AM +0100, Krzysztof Kozlowski wrote: > > > > That's not true. There is no waste because having it on x86 allows to > > match via ACPI PRP0001. It's on purpose there. > > Alright how about this, I don't have any OF devices on my machine > yet this structure is still taking up the extra memory for every > single device driver. This is wrong. > > > There are OF-drivers used on ACPI and x86/arm64. > > Well then they should be selecting OF and everyone will be happy. > No. PRP0001 support in ACPI does not depend on OF, so drivers that may be bound to such devices should not either. If you are concerned about the memory used by such tables, you can always propose making PRP0001 support configurable in the ACPI core, but making individual devices depend on OF for PRP0001 matching seems wrong to me.
On Thu, Mar 23, 2023 at 09:43:58AM +0100, Ard Biesheuvel wrote: > > No. PRP0001 support in ACPI does not depend on OF, so drivers that may > be bound to such devices should not either. > > If you are concerned about the memory used by such tables, you can > always propose making PRP0001 support configurable in the ACPI core, > but making individual devices depend on OF for PRP0001 matching seems > wrong to me. What I am against is removing of_match_ptr by doing a million tiny patches. Either we should keep it, in which case the of_match_table field should be made conditional on OF or perhaps a new Kconfig option if there is no way to reconcile this with ACPI, or we decide to get rid of it and you should do one giant patch to remove of_match_ptr across the kernel tree. We should not be doing a patch for every single driver that has of_match_table based on whether it can or cannot be used through ACPI. Cheers,
diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c index fe93d19e3044..4e9a6660d791 100644 --- a/drivers/crypto/img-hash.c +++ b/drivers/crypto/img-hash.c @@ -1106,7 +1106,7 @@ static struct platform_driver img_hash_driver = { .driver = { .name = "img-hash-accelerator", .pm = &img_hash_pm_ops, - .of_match_table = of_match_ptr(img_hash_match), + .of_match_table = img_hash_match, } }; module_platform_driver(img_hash_driver);