[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb72b4e4-d5c6-d9be-269d-29aff996001c@foss.st.com>
Date: Mon, 10 Jul 2023 10:22:10 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: Rob Herring <robh@...nel.org>
CC: <Oleksii_Moisieiev@...m.com>, <gregkh@...uxfoundation.org>,
<herbert@...dor.apana.org.au>, <davem@...emloft.net>,
<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
<alexandre.torgue@...s.st.com>, <vkoul@...nel.org>, <jic23@...nel.org>,
<olivier.moysan@...s.st.com>, <arnaud.pouliquen@...s.st.com>,
<mchehab@...nel.org>, <fabrice.gasnier@...s.st.com>,
<andi.shyti@...nel.org>, <ulf.hansson@...aro.org>,
<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
<hugues.fruchet@...s.st.com>, <lee@...nel.org>, <will@...nel.org>,
<catalin.marinas@....com>, <arnd@...nel.org>,
<richardcochran@...il.com>, <linux-crypto@...r.kernel.org>,
<devicetree@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
<dmaengine@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
<linux-iio@...r.kernel.org>, <alsa-devel@...a-project.org>,
<linux-media@...r.kernel.org>, <linux-mmc@...r.kernel.org>,
<netdev@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
<linux-serial@...r.kernel.org>, <linux-spi@...r.kernel.org>,
<linux-usb@...r.kernel.org>
Subject: Re: [PATCH 04/10] dt-bindings: treewide: add feature-domains
description in binding files
On 7/7/23 17:20, Rob Herring wrote:
> On Fri, Jul 07, 2023 at 02:28:28PM +0200, Gatien CHEVALLIER wrote:
>> Hello Rob,
>>
>> On 7/6/23 16:51, Rob Herring wrote:
>>> On Wed, Jul 05, 2023 at 07:27:53PM +0200, Gatien Chevallier wrote:
>>>> feature-domains is an optional property that allows a peripheral to
>>>> refer to one or more feature domain controller(s).
>>>>
>>>> Description of this property is added to all peripheral binding files of
>>>> the peripheral under the STM32 firewall controllers. It allows an accurate
>>>> representation of the hardware, where various peripherals are connected
>>>> to this firewall bus. The firewall can then check the peripheral accesses
>>>> before allowing it to probe.
>>>>
>>>> Signed-off-by: Gatien Chevallier <gatien.chevallier@...s.st.com>
>>>> ---
>>>>
>>>> Disclaimer: Some error with dtbs_check will be observed as I've
>>>> considered the property to be generic, as Rob asked
>>>>
>>>> Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/dma/st,stm32-dma.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml | 4 ++++
>>>> .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml | 4 ++++
>>>> .../devicetree/bindings/media/cec/st,stm32-cec.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml | 4 ++++
>>>> .../bindings/memory-controllers/st,stm32-fmc2-ebi.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml | 5 +++++
>>>> Documentation/devicetree/bindings/mmc/arm,pl18x.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml | 4 ++++
>>>> .../devicetree/bindings/regulator/st,stm32-vrefbuf.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/rng/st,stm32-rng.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/sound/st,stm32-sai.yaml | 4 ++++
>>>> .../devicetree/bindings/sound/st,stm32-spdifrx.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/spi/st,stm32-spi.yaml | 4 ++++
>>>> Documentation/devicetree/bindings/usb/dwc2.yaml | 4 ++++
>>>> 24 files changed, 97 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
>>>> index b767ec72a999..daf8dcaef627 100644
>>>> --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
>>>> +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
>>>> @@ -50,6 +50,10 @@ properties:
>>>> power-domains:
>>>> maxItems: 1
>>>> + feature-domains:
>>>> + minItems: 1
>>>> + maxItems: 3
>>>
>>> What are the 3 entries?
>>>
>>> Rob
>>
>> I thought I was benefiting from the description of the pattern-property in
>> the RIFSC YAML file. But yes anyway, it seems like it needs some description
>> here as the dependency does not appear in this file.
>
> Humm, that should limit the maximum entries to 2, so 3 would never work
> (if RIFSC is the parent).
>
>> I picked 3 as a maxItems for our ST needs, I'll give it some more thought
>> when coming back with something clearer.
>
> I'd expect you have 1 entry for register bus and 1 entry for DMA bus if
> there is one. It's block specific for how many entries, so the RIFSC
> schema should not be setting that. You could possibly say that
> 'feature-domains' is required for all the child nodes though.
Ok, I will change to not specifying the number of entries in the
RIFSC YAML file for V2.
>
> Rob
Some hardware blocks may have a firewall ID for their device part and
another ID for their master part as well. In the end, the number of
entries could very well vary between different platforms. And the YAML
files are common to these platforms.
This property could be used for "extra" arguments as well, that are not
firewall IDs.
What do you suggest between picking a high maxItems value that would
(hopefully) cover all cases and not specifying maxItems at all? Or maybe
another property dedicated to such arguments?
Best regards,
Gatien
Powered by blists - more mailing lists