Message ID | 20221014172324.1.Ifc1812116ff63f5501f3edd155d3cf5c0ecc846c@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp240838wrs; Fri, 14 Oct 2022 08:26:08 -0700 (PDT) X-Google-Smtp-Source: AMsMyM646SWQ4HEPh8WbDGEESVyDsBdZMVuUkmRAJSprdRnSVARtfMIY682I/CilO/pIfe2PWf7v X-Received: by 2002:a17:903:1105:b0:178:ae31:aad with SMTP id n5-20020a170903110500b00178ae310aadmr5818183plh.3.1665761167953; Fri, 14 Oct 2022 08:26:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665761167; cv=none; d=google.com; s=arc-20160816; b=KHsBevj1DRf4uDvnYN4H1Ib3xDj9mtYpgCwELX/YisccfhpBVgCSPYbqlfysqhwcnr MkudDJ6mZyZMu4QV+/fL2jnRI/fN8tMGxlmeLUB4pICcJQ/ASovTp53Xs/f7j9r6EswI Os6UyePUS90t+wETpmP/C2a34mBF54iWVYKc9tr7vuDUllNc8SSqFZuxKR4t7dG6WQeZ ZKG+ES7Nv48NZd1K95UXOfLr409KIt63CQEa8OHC8zKT5eCPdJPgAEC0geaTNaD7uSln y2lSrjzH16OgxeOcYOLBKtGDWf/ZfEnIliI1Lm14CuCI4SjncabuKN7Rwta/gTh4bLU4 UmkA== 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:cc:to:from:dkim-signature; bh=XxmR9+2YKarx682UHje/1a7OQNTotC8Yrb+nb/cNJ6A=; b=0esQ3SYZP37lUwYxUO1WTh5Hw7u2h24s+YPsTyc0VcILUh0T75sO/bUOQJc9+rUEVt MW6dW/fZHP8FTb5SZjAFNCCVtkgOXEFcApm4EKETk09E0uP5c6xIa5un2ImFmJ3HaJ5F EDvXnpMDqsfSOwtxbVsFVO+OeJqPoFSJjmP12NVQtIge0uLOZ2hUwRAM97AEsWQktgdb 7O9YULHe8zd3iBrI12mYtZG2mUdyMTJh6XbVQxPN3MD5rxWhWUz1bHNVIw/RwY0IBGTA Zhq6QcHRczvBMACRQv1iHjH2WiO46xg1duxrdzVIb6oevQWPJcbgq13NIjT4zsL6RhMH TzVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=nW+A2DIf; 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=foss.st.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y187-20020a638ac4000000b004630aa449c2si3001938pgd.242.2022.10.14.08.25.55; Fri, 14 Oct 2022 08:26:07 -0700 (PDT) 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=@foss.st.com header.s=selector1 header.b=nW+A2DIf; 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=foss.st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230129AbiJNPYq (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Fri, 14 Oct 2022 11:24:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230150AbiJNPYm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Oct 2022 11:24:42 -0400 Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0990F15A32C; Fri, 14 Oct 2022 08:24:31 -0700 (PDT) Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29EF5CXq031283; Fri, 14 Oct 2022 17:23:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=selector1; bh=XxmR9+2YKarx682UHje/1a7OQNTotC8Yrb+nb/cNJ6A=; b=nW+A2DIfoop2HPybGIkjsA0Q1WmhUlgaxEAloKgDvDBHgRpUcN21iG5vLWkbbxV7CgcB RO/e+HcYfzTAFf1zm/qK94cUPSPfLuE9aK1UeBxISdYEdahkqbGs6U87NutOQDScDlCm aoGQlL5h4MopPAPgjUmpUYRMqMdLPrrcsKSfb8iWbCI66vAqnU/Zoe4nr/oMo57oInwA 7FtPegwj7cLyFjJzqPa20oapcFY/z24o0nm4yOft4Uy/sComyYTabTtz8oNA7+0F8aud C5gNKkJwkee0UFVU1cdxN/4Oj8gMDod9cLbF8vVaaNTL+CAdStfnaQ+yBX3+TsSUyrpm 7A== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3k64m7xf0p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Oct 2022 17:23:36 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B403A10002A; Fri, 14 Oct 2022 17:23:31 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id ACA5D235F3B; Fri, 14 Oct 2022 17:23:31 +0200 (CEST) Received: from localhost (10.75.127.123) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.31; Fri, 14 Oct 2022 17:23:28 +0200 From: Patrick Delaunay <patrick.delaunay@foss.st.com> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Fabrice Gasnier <fabrice.gasnier@foss.st.com> CC: Patrick Delaunay <patrick.delaunay@foss.st.com>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com> Subject: [PATCH] dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem Date: Fri, 14 Oct 2022 17:23:27 +0200 Message-ID: <20221014172324.1.Ifc1812116ff63f5501f3edd155d3cf5c0ecc846c@changeid> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.75.127.123] X-ClientProxiedBy: GPXDAG2NODE4.st.com (10.75.127.68) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-14_08,2022-10-14_01,2022-06-22_01 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS 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?1746677182426954324?= X-GMAIL-MSGID: =?utf-8?q?1746677182426954324?= |
Series |
dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem
|
|
Commit Message
Patrick Delaunay
Oct. 14, 2022, 3:23 p.m. UTC
Add a new compatible for stm32mp13 support.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
---
Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml | 1 +
1 file changed, 1 insertion(+)
Comments
On Fri, 14 Oct 2022 17:23:27 +0200, Patrick Delaunay wrote: > Add a new compatible for stm32mp13 support. > > Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> > --- > > Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring <robh@kernel.org>
On 14/10/2022 11:23, Patrick Delaunay wrote: > Add a new compatible for stm32mp13 support. > > Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> > --- > > Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml > index 448a2678dc62..16f4cad2fa55 100644 > --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml > +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml > @@ -22,6 +22,7 @@ properties: > compatible: > enum: > - st,stm32f4-otp > + - st,stm32mp13-bsec > - st,stm32mp15-bsec According to usage in DTS (separate patch for some reason), the devices are compatible, so please describe them like that. Best regards, Krzysztof
Hi, On 10/18/22 03:56, Krzysztof Kozlowski wrote: > On 14/10/2022 11:23, Patrick Delaunay wrote: >> Add a new compatible for stm32mp13 support. >> >> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> >> --- >> >> Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >> index 448a2678dc62..16f4cad2fa55 100644 >> --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >> +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >> @@ -22,6 +22,7 @@ properties: >> compatible: >> enum: >> - st,stm32f4-otp >> + - st,stm32mp13-bsec >> - st,stm32mp15-bsec > According to usage in DTS (separate patch for some reason), the devices > are compatible, so please describe them like that. I push the separate patch "ARM: dts: stm32mp13: fix compatible for BSEC" It is a advice of my colleagues: send an update of device tree only when the binding modification is acked. Sorry for disturbance, I can sent a V2 with the 2 patches. The STM32MP15 and STM32MP13 don't use the same version of the BSEC device, and the driver need to handle it. In these 2 patches: - [PATCH] dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem - [PATCH] ARM: dts: stm32mp13: fix compatible for BSEC I fix a error for BSEC node in the initial patch to support STM32MP13x, the DTS "stm32mp131.dtsi" should not used/accepted with the a BSEC node using the compatible "st,stm32mp15-bsec" in commit 1da8779c0029 ("ARM: dts: stm32: add STM32MP13 SoCs support") It is a preliminary step to add support of STM32MP13x in STM32 ROMEM driver. I don't indicate these patches as "Fixes:" to avoid a dts check issue if only the DTS patch was backported. Today it not blocking for STM32MP13x users because this SoC is not yet available for customers and it is only used internally on the ST Microelectronics board STM32MP135F-DK. Nobody (except STMicroelectronics) use this SoC STM32MP13x with the current DTS / Linux version. Moreover, by default, the STM32 ROMEM driver in not activated in any defconfig, I prepare a other patch to activated it by default in arm_multiv7_defconfig. but I am waiting this DTS correction to avoid to probe the stm32 romen driver with STM32MP15 configuration on STM32MP13x SoC. I think is a good time to update this DTS error before the SoC availability, agreed with SoC Maintainer, Alexandre Torgue, even if this patch breaks surrent users of STM32MP13x DTS (but it is only internals user STMicroelectronics until now). but perhaps you prefer a other solution ? add Fixes in the DTS patch ? + Fixes: 1da8779c0029 ("ARM: dts: stm32: add STM32MP13 SoCs support") or bsec: efuse@5c005000 { compatible = "st,stm32mp13-bsec", "st,stm32mp15-bsec"; sorry, I misses to share this context. > > Best regards, > Krzysztof Regards Patrick
On 19/10/2022 13:23, Patrick DELAUNAY wrote: > Hi, > > On 10/18/22 03:56, Krzysztof Kozlowski wrote: >> On 14/10/2022 11:23, Patrick Delaunay wrote: >>> Add a new compatible for stm32mp13 support. >>> >>> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> >>> --- >>> >>> Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >>> index 448a2678dc62..16f4cad2fa55 100644 >>> --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >>> +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >>> @@ -22,6 +22,7 @@ properties: >>> compatible: >>> enum: >>> - st,stm32f4-otp >>> + - st,stm32mp13-bsec >>> - st,stm32mp15-bsec >> According to usage in DTS (separate patch for some reason), the devices >> are compatible, so please describe them like that. > > > I push the separate patch "ARM: dts: stm32mp13: fix compatible for BSEC" > > It is a advice of my colleagues: send an update of device tree > > only when the binding modification is acked. That's not correct advice - only for few cases it's valid (when subsystem maintainer wants to take entire patchset, so there should be no DTS inside). We want to see the bindings and its usage, so one of: 1. the same patchset 2. if two patchsets, then cross linked to each other with URLs to lore.kernel.org. I see DTS had link but not this one. Driver changes also must be sent together with the bindings. Since there are no driver changes here, it means for us the devices are compatible from Linux point of view. > > > Sorry for disturbance, I can sent a V2 with the 2 patches. > > > The STM32MP15 and STM32MP13 don't use the same version of the BSEC device, > > and the driver need to handle it. > > > In these 2 patches: > > - [PATCH] dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem > > - [PATCH] ARM: dts: stm32mp13: fix compatible for BSEC > > > I fix a error for BSEC node in the initial patch to support STM32MP13x, The question is then whether device was working before or not. If it was working, you fix one error but break DTS usage on any system which does not have updated driver (so BSD, u-boot, other firmware, other Linux kernel versions). If it was not working, then it's okay, but such case was not explained in DTS patch, I think. > > the DTS "stm32mp131.dtsi" should not used/accepted with the a BSEC node > using > > the compatible "st,stm32mp15-bsec" in commit 1da8779c0029 ("ARM: dts: > stm32: add STM32MP13 SoCs support") > > > It is a preliminary step to add support of STM32MP13x in STM32 ROMEM driver. > > > I don't indicate these patches as "Fixes:" to avoid a dts check issue > > if only the DTS patch was backported. > > > Today it not blocking for STM32MP13x users because this SoC is not yet > available for customers > > and it is only used internally on the ST Microelectronics board > STM32MP135F-DK. DTS patch says nothing about it... > > > Nobody (except STMicroelectronics) use this SoC STM32MP13x with the > current DTS / Linux version. > > > Moreover, by default, the STM32 ROMEM driver in not activated in any > defconfig, Independent issue. > > I prepare a other patch to activated it by default in arm_multiv7_defconfig. > > but I am waiting this DTS correction to avoid to probe the stm32 romen > driver with STM32MP15 > > configuration on STM32MP13x SoC. > > > I think is a good time to update this DTS error before the SoC availability, > > agreed with SoC Maintainer, Alexandre Torgue, even if this patch breaks > surrent users > > of STM32MP13x DTS (but it is only internals user STMicroelectronics > until now). > > > but perhaps you prefer a other solution ? With that explanation it is fine, but the DTS commit was not mentioning explanation. > > add Fixes in the DTS patch ? > > + Fixes: 1da8779c0029 ("ARM: dts: stm32: add STM32MP13 SoCs support") > > or > > > bsec: efuse@5c005000 { > compatible = "st,stm32mp13-bsec", "st,stm32mp15-bsec"; Depends whether devices are compatible or not. Best regards, Krzysztof
Hi, On 10/20/22 14:48, Krzysztof Kozlowski wrote: > On 19/10/2022 13:23, Patrick DELAUNAY wrote: >> Hi, >> >> On 10/18/22 03:56, Krzysztof Kozlowski wrote: >>> On 14/10/2022 11:23, Patrick Delaunay wrote: >>>> Add a new compatible for stm32mp13 support. >>>> >>>> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> >>>> --- >>>> >>>> Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >>>> index 448a2678dc62..16f4cad2fa55 100644 >>>> --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >>>> +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml >>>> @@ -22,6 +22,7 @@ properties: >>>> compatible: >>>> enum: >>>> - st,stm32f4-otp >>>> + - st,stm32mp13-bsec >>>> - st,stm32mp15-bsec >>> According to usage in DTS (separate patch for some reason), the devices >>> are compatible, so please describe them like that. >> >> I push the separate patch "ARM: dts: stm32mp13: fix compatible for BSEC" >> >> It is a advice of my colleagues: send an update of device tree >> >> only when the binding modification is acked. > That's not correct advice - only for few cases it's valid (when > subsystem maintainer wants to take entire patchset, so there should be > no DTS inside). We want to see the bindings and its usage, so one of: > 1. the same patchset > 2. if two patchsets, then cross linked to each other with URLs to > lore.kernel.org. I see DTS had link but not this one. > > Driver changes also must be sent together with the bindings. Since there > are no driver changes here, it means for us the devices are compatible > from Linux point of view. > >> >> Sorry for disturbance, I can sent a V2 with the 2 patches. >> >> >> The STM32MP15 and STM32MP13 don't use the same version of the BSEC device, >> >> and the driver need to handle it. >> >> >> In these 2 patches: >> >> - [PATCH] dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem >> >> - [PATCH] ARM: dts: stm32mp13: fix compatible for BSEC >> >> >> I fix a error for BSEC node in the initial patch to support STM32MP13x, > The question is then whether device was working before or not. If it was > working, you fix one error but break DTS usage on any system which does > not have updated driver (so BSD, u-boot, other firmware, other Linux > kernel versions). > > If it was not working, then it's okay, but such case was not explained > in DTS patch, I think. > >> the DTS "stm32mp131.dtsi" should not used/accepted with the a BSEC node >> using >> >> the compatible "st,stm32mp15-bsec" in commit 1da8779c0029 ("ARM: dts: >> stm32: add STM32MP13 SoCs support") >> >> >> It is a preliminary step to add support of STM32MP13x in STM32 ROMEM driver. >> >> >> I don't indicate these patches as "Fixes:" to avoid a dts check issue >> >> if only the DTS patch was backported. >> >> >> Today it not blocking for STM32MP13x users because this SoC is not yet >> available for customers >> >> and it is only used internally on the ST Microelectronics board >> STM32MP135F-DK. > DTS patch says nothing about it... > >> >> Nobody (except STMicroelectronics) use this SoC STM32MP13x with the >> current DTS / Linux version. >> >> >> Moreover, by default, the STM32 ROMEM driver in not activated in any >> defconfig, > Independent issue. > >> I prepare a other patch to activated it by default in arm_multiv7_defconfig. >> >> but I am waiting this DTS correction to avoid to probe the stm32 romen >> driver with STM32MP15 >> >> configuration on STM32MP13x SoC. >> >> >> I think is a good time to update this DTS error before the SoC availability, >> >> agreed with SoC Maintainer, Alexandre Torgue, even if this patch breaks >> surrent users >> >> of STM32MP13x DTS (but it is only internals user STMicroelectronics >> until now). >> >> >> but perhaps you prefer a other solution ? > With that explanation it is fine, but the DTS commit was not mentioning > explanation. OK > >> add Fixes in the DTS patch ? >> >> + Fixes: 1da8779c0029 ("ARM: dts: stm32: add STM32MP13 SoCs support") >> >> or >> >> >> bsec: efuse@5c005000 { >> compatible = "st,stm32mp13-bsec", "st,stm32mp15-bsec"; > > Depends whether devices are compatible or not. > > Best regards, > Krzysztof > For device point of view, the BSEC used on STM32MP13 have few corrections wich need to be managed in the driver. But for driver point of view, as the BSEC IP is secured on STM32MP13 the IP is managed by OP-TEE, acess should be provided with TA / OP-TEE and some obcolete features will be never supported (access to OTP with proprietary SMC: STM32_SMC_BSEC) on STM32MP13x SoC. The device are not compatibles in the 2 SoC, I will sent a V2 with cover letter + binding, DT and driver modification to be more clear. Regards Patrick
diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml index 448a2678dc62..16f4cad2fa55 100644 --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml @@ -22,6 +22,7 @@ properties: compatible: enum: - st,stm32f4-otp + - st,stm32mp13-bsec - st,stm32mp15-bsec reg: