From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC676EE4996 for ; Mon, 21 Aug 2023 13:13:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235310AbjHUNNI (ORCPT ); Mon, 21 Aug 2023 09:13:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235314AbjHUNM7 (ORCPT ); Mon, 21 Aug 2023 09:12:59 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12DA5102 for ; Mon, 21 Aug 2023 06:12:51 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-99c0cb7285fso421330366b.0 for ; Mon, 21 Aug 2023 06:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692623569; x=1693228369; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ph4bj2JE9yzl4L+Z7YlL2YAhIXL0uO8/2XI9ntDToVQ=; b=l3oOXCGGKIiNhVVOlEdUewd/pmvcytIseBPXpgOdpkQcQ8thjGggHgxO6SgeTjYdh/ Egbmj8KyYS9b0Ml3zehz/FNy2ccVIBDmidw77jIUO3UxVNLyCFPqkg1TU6AVowYNaxbk 7Re97yiggHYJLaVWGJtA/5XtTlOV+hOajq9MIpbJP9ouYdXIp2IB6OxybJSacgq70GLv nWXUXx1Lc4T/JOJAR/BZbsrm3K6ZaiyczBZUZC0r0PolzeSZY2pQiIzPJetJYNzYOsKC z5SZ0/NBdGoTFnqRfdv094jDhnmQvIDkn99/TqEE+MfHXSmpDflPXlDVQsbjvSyDwfoZ Qh3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692623569; x=1693228369; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ph4bj2JE9yzl4L+Z7YlL2YAhIXL0uO8/2XI9ntDToVQ=; b=NpPj7Ba7XkcAnMVvQqzhvDzKipzj+eUxY5OBdiJEf0121tw1MmdblSKTeKgZqOrJRr Mz6mC0Y4WYTHnEmzFb1NekZIqg0cOIFWH5oR6+mcxkiDxqaxHjGx+TJhkxnvixnowSbJ u9MNbBlKfl0LeeRh1uIwTEJ3Ft2++zkqPdqYxkX5o6kM63jYqH2TtxJp3Zlx1IxGSNE3 YMNc2KFcfSaxCFiahduVz94adyS0gf7WN7MtAcscAyUvp1ASLXQBdEgU294Rv5mAPfjJ GaMTAbixUC/umZ7Nxfc+j7i3bcWxpq2Jl3N9T8PK7+60rsXcxn7dO4LPEmaGQbjM2qnz mcEQ== X-Gm-Message-State: AOJu0YzOAu8WtkFVevN4rD1LYH84jSPKmX/DSoxZFhJG64SeKqEm867j oLdY9ZZtU3GzNXGTR+wMQ2JbNg== X-Google-Smtp-Source: AGHT+IH+3SmODhee1b7JSmRuMG8rb8itCh0JRCEBqsSoEyQCgOdF9obSTVQzCaITVsL+R6gKVO4F1Q== X-Received: by 2002:a17:906:21c:b0:99e:13f6:8a5a with SMTP id 28-20020a170906021c00b0099e13f68a5amr4759565ejd.20.1692623569387; Mon, 21 Aug 2023 06:12:49 -0700 (PDT) Received: from [192.168.0.22] ([77.252.47.198]) by smtp.gmail.com with ESMTPSA id lw26-20020a170906bcda00b00993a37aebc5sm6438076ejb.50.2023.08.21.06.12.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Aug 2023 06:12:48 -0700 (PDT) Message-ID: <342de8f3-852f-9bfa-39c4-4d820f349305@linaro.org> Date: Mon, 21 Aug 2023 15:12:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v3 11/50] dt-bindings: crypto: add sam9x7 in Atmel TDES Content-Language: en-US To: Tudor Ambarus , Nicolas Ferre , Varshini.Rajendran@microchip.com, herbert@gondor.apana.org.au, davem@davemloft.net, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, alexandre.belloni@bootlin.com, claudiu.beznea@microchip.com, linux-crypto@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20230728102442.265820-1-varshini.rajendran@microchip.com> <09bd1388-02aa-32c7-319e-d7150a0f3e9c@linaro.org> <1ec901d0-44c2-1d28-5976-d93abfffee67@microchip.com> <37782447-43c7-50f9-b9b4-5fbca94ce8c6@linaro.org> <96033a59-a2ea-c906-a033-84119c5783d7@linaro.org> <57e9a9ff-26ed-62d1-91f8-cd5596f1c308@linaro.org> <5235260c-8fd6-2b2a-58b9-703191fff526@linaro.org> <697712da-bff9-4621-28ac-9c9f68a76e43@linaro.org> From: Krzysztof Kozlowski In-Reply-To: <697712da-bff9-4621-28ac-9c9f68a76e43@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On 21/08/2023 15:00, Tudor Ambarus wrote: > > > On 8/21/23 13:10, Krzysztof Kozlowski wrote: >> On 21/08/2023 11:54, Tudor Ambarus wrote: >>>>>>> I am aware that there is no change in the crypto IP used. This patch is >>>> >>>> Actually, recent history showed us that it's not only the IP itself but >>>> its integration into final product that could have an influence on the >>>> behavior. >>>> >>>>>>> to add a SoC specific compatible as expected by writing-bindings >>>>>>> guideline. Maybe a bit more explanation in the commit description might >>>>>>> do the trick. >>>>>>> >>>>>> >>>>>> So you add a compatible that will never be used just to comply with >>>>>> the writing bindings guideline? >>>>> >>>>> How do you know that it is never going to be used? The guideline asks >>> >>> See >>> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git/tree/drivers/crypto/atmel-tdes.c?h=at91-dt#n1120 >> >> What's there? One compatible? How does it prove that it will not be >> used? It only proves that currently it is not used... And anyway this is > > Correct, as of now the compatible was not used to determine the hw caps, > the capabilities were retrieved by checking at runtime a version > register. I'm against adding a compatible that will not be used, in this > particular case, defining "microchip,sam9x7-tdes" in the driver but > still solely relying on the runtime version register interrogation. > Unfortunately the commit message does not reveal any intention and from > there these emails changed. Maybe it's just a matter of personal > preference, so I'll stop commenting on this. Hm, thanks for bringing this up, indeed it looks a bit redundant to have additional compatible strings if HW can identify itself. In such case, pretty often a generic compatible in the driver and DTS could do... but: 1. Adding specific compatibles for such case would have sense to be able to validate differences between DTS (like clocks, resets and power domains). 2. Reading HW revision might require enabling clocks which might differ per variant, thus driver still might need to match according to some compatibles. After that matching, driver can get necessary clocks, enable them and read the HW version/revision. There is an example for this: Documentation/devicetree/bindings/cache/qcom,llcc.yaml drivers/soc/qcom/llcc-qcom.c We have there version of the block but clocks and register layout differ, thus we must have device-specific compatibles. > >> just one implementation in one system. How can you possibly know all >> other possible implementations (other bootloaders/firmwares/systems)? >> One cannot. The guideline is there for specific reason. >> > > I didn't say the guideline is wrong, I just tried to understand how this > particular case is handled. >> Best regards, Krzysztof From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B2C93EE4993 for ; Mon, 21 Aug 2023 13:13:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zEVd50LaQJXZxWCG7EMInuTNIMRnApn3o2wqc0BQMog=; b=b70AyKjwQWqR05 E7qs++wBVYuEfOWkBIItX7ZrcJrFj0HH1+QXt3FsZyMofq+C08P4xFDNyU9d0xFmEm4v0YgQqzgww S3W6sP6OoEQAN4TGzVG0xH87aEEP0FqJPwbS36UfFYf0DZv0Wp642gMRy5smYz5BtTblFSqTh1MS7 vnsLE8YUGz42RzYjALikmh4Z1o28tVyppQZKuqwU5F0wMGIh6Nb5rwOFHecIfEYHE0hpEeyxavhC/ 8QxxtgAZ1cJ2NeLOQk32umD0zLfJ0Cgu8odZfutniJntfFG49aFeJCQIBo9/W3yM+m6nE081TJduE Cd3Imov4WmcuusxDas8A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qY4iG-00E3b8-2U; Mon, 21 Aug 2023 13:12:56 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qY4iD-00E3ZV-1K for linux-arm-kernel@lists.infradead.org; Mon, 21 Aug 2023 13:12:55 +0000 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-9a19bf6ab66so90917966b.3 for ; Mon, 21 Aug 2023 06:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692623569; x=1693228369; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ph4bj2JE9yzl4L+Z7YlL2YAhIXL0uO8/2XI9ntDToVQ=; b=l3oOXCGGKIiNhVVOlEdUewd/pmvcytIseBPXpgOdpkQcQ8thjGggHgxO6SgeTjYdh/ Egbmj8KyYS9b0Ml3zehz/FNy2ccVIBDmidw77jIUO3UxVNLyCFPqkg1TU6AVowYNaxbk 7Re97yiggHYJLaVWGJtA/5XtTlOV+hOajq9MIpbJP9ouYdXIp2IB6OxybJSacgq70GLv nWXUXx1Lc4T/JOJAR/BZbsrm3K6ZaiyczBZUZC0r0PolzeSZY2pQiIzPJetJYNzYOsKC z5SZ0/NBdGoTFnqRfdv094jDhnmQvIDkn99/TqEE+MfHXSmpDflPXlDVQsbjvSyDwfoZ Qh3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692623569; x=1693228369; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ph4bj2JE9yzl4L+Z7YlL2YAhIXL0uO8/2XI9ntDToVQ=; b=faM1N3TbFA6T8e3gwXbOv2o1ptkQe16vduCghlnwk/16yvmnUN4+wpqf+jP98s6EKx cwGhOin7AWCdKSTJ54i2Fh4s9rgNTLgVkog2g1rvEQIENclQHtmlOdOeOU9laTo6rfOO 3VXfhZQ8TDjzmEBnH7DdSTU84OsRSEf8br04PcXMLQkaan3AmI92awi8KmN9u91cdg6m M/243dKI1sngGN9y+Ca42FmWwOAHbUttd0VyCwsQ7D2va9wPJqeuW42XVsafhidgUAH0 guxM9X9V7MGT9mh8yuPkv1ySWE/V/J8GkRLTx5QjiVpAiiWMkbyMp4cuJLmbvqJP61S2 pRzg== X-Gm-Message-State: AOJu0YyAlQImDAkhxg5ogIvxc9qXc52OR7AVDhZWaUrn6nNcL4jiqRkT t1IHF6Wx4nUQ8iJfgg+IrpFSbw== X-Google-Smtp-Source: AGHT+IH+3SmODhee1b7JSmRuMG8rb8itCh0JRCEBqsSoEyQCgOdF9obSTVQzCaITVsL+R6gKVO4F1Q== X-Received: by 2002:a17:906:21c:b0:99e:13f6:8a5a with SMTP id 28-20020a170906021c00b0099e13f68a5amr4759565ejd.20.1692623569387; Mon, 21 Aug 2023 06:12:49 -0700 (PDT) Received: from [192.168.0.22] ([77.252.47.198]) by smtp.gmail.com with ESMTPSA id lw26-20020a170906bcda00b00993a37aebc5sm6438076ejb.50.2023.08.21.06.12.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Aug 2023 06:12:48 -0700 (PDT) Message-ID: <342de8f3-852f-9bfa-39c4-4d820f349305@linaro.org> Date: Mon, 21 Aug 2023 15:12:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v3 11/50] dt-bindings: crypto: add sam9x7 in Atmel TDES Content-Language: en-US To: Tudor Ambarus , Nicolas Ferre , Varshini.Rajendran@microchip.com, herbert@gondor.apana.org.au, davem@davemloft.net, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, alexandre.belloni@bootlin.com, claudiu.beznea@microchip.com, linux-crypto@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20230728102442.265820-1-varshini.rajendran@microchip.com> <09bd1388-02aa-32c7-319e-d7150a0f3e9c@linaro.org> <1ec901d0-44c2-1d28-5976-d93abfffee67@microchip.com> <37782447-43c7-50f9-b9b4-5fbca94ce8c6@linaro.org> <96033a59-a2ea-c906-a033-84119c5783d7@linaro.org> <57e9a9ff-26ed-62d1-91f8-cd5596f1c308@linaro.org> <5235260c-8fd6-2b2a-58b9-703191fff526@linaro.org> <697712da-bff9-4621-28ac-9c9f68a76e43@linaro.org> From: Krzysztof Kozlowski In-Reply-To: <697712da-bff9-4621-28ac-9c9f68a76e43@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230821_061253_453027_964CDD37 X-CRM114-Status: GOOD ( 24.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 21/08/2023 15:00, Tudor Ambarus wrote: > > > On 8/21/23 13:10, Krzysztof Kozlowski wrote: >> On 21/08/2023 11:54, Tudor Ambarus wrote: >>>>>>> I am aware that there is no change in the crypto IP used. This patch is >>>> >>>> Actually, recent history showed us that it's not only the IP itself but >>>> its integration into final product that could have an influence on the >>>> behavior. >>>> >>>>>>> to add a SoC specific compatible as expected by writing-bindings >>>>>>> guideline. Maybe a bit more explanation in the commit description might >>>>>>> do the trick. >>>>>>> >>>>>> >>>>>> So you add a compatible that will never be used just to comply with >>>>>> the writing bindings guideline? >>>>> >>>>> How do you know that it is never going to be used? The guideline asks >>> >>> See >>> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git/tree/drivers/crypto/atmel-tdes.c?h=at91-dt#n1120 >> >> What's there? One compatible? How does it prove that it will not be >> used? It only proves that currently it is not used... And anyway this is > > Correct, as of now the compatible was not used to determine the hw caps, > the capabilities were retrieved by checking at runtime a version > register. I'm against adding a compatible that will not be used, in this > particular case, defining "microchip,sam9x7-tdes" in the driver but > still solely relying on the runtime version register interrogation. > Unfortunately the commit message does not reveal any intention and from > there these emails changed. Maybe it's just a matter of personal > preference, so I'll stop commenting on this. Hm, thanks for bringing this up, indeed it looks a bit redundant to have additional compatible strings if HW can identify itself. In such case, pretty often a generic compatible in the driver and DTS could do... but: 1. Adding specific compatibles for such case would have sense to be able to validate differences between DTS (like clocks, resets and power domains). 2. Reading HW revision might require enabling clocks which might differ per variant, thus driver still might need to match according to some compatibles. After that matching, driver can get necessary clocks, enable them and read the HW version/revision. There is an example for this: Documentation/devicetree/bindings/cache/qcom,llcc.yaml drivers/soc/qcom/llcc-qcom.c We have there version of the block but clocks and register layout differ, thus we must have device-specific compatibles. > >> just one implementation in one system. How can you possibly know all >> other possible implementations (other bootloaders/firmwares/systems)? >> One cannot. The guideline is there for specific reason. >> > > I didn't say the guideline is wrong, I just tried to understand how this > particular case is handled. >> Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel