| Message ID | 20220208104918.226156-2-tudor.ambarus@microchip.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | crypto: Convert atmel-crypto to YAML | expand |
On 08/02/2022 11:49, Tudor Ambarus wrote: > Convert Atmel AES documentation to yaml format. With the conversion the > clock and clock-names properties are made mandatory. The driver returns > -EINVAL if "aes_clk" is not found, reflect that in the bindings and make > the clock and clock-names properties mandatory. Update the example to > better describe how one should define the dt node. > > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> > --- > .../crypto/atmel,at91sam9g46-aes.yaml | 65 +++++++++++++++++++ > .../bindings/crypto/atmel-crypto.txt | 20 ------ > 2 files changed, 65 insertions(+), 20 deletions(-) > create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml > I understand that you keep the license GPL-2.0 (not recommended mix) because of example coming from previous bindings or from DTS (both GPL-2.0)? Best regards, Krzysztof
On 2/8/22 13:58, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 08/02/2022 11:49, Tudor Ambarus wrote: >> Convert Atmel AES documentation to yaml format. With the conversion the >> clock and clock-names properties are made mandatory. The driver returns >> -EINVAL if "aes_clk" is not found, reflect that in the bindings and make >> the clock and clock-names properties mandatory. Update the example to >> better describe how one should define the dt node. >> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> >> --- >> .../crypto/atmel,at91sam9g46-aes.yaml | 65 +++++++++++++++++++ >> .../bindings/crypto/atmel-crypto.txt | 20 ------ >> 2 files changed, 65 insertions(+), 20 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml >> > > I understand that you keep the license GPL-2.0 (not recommended mix) > because of example coming from previous bindings or from DTS (both GPL-2.0)? > The previous bindings did not have a license specified. We have DTS files with these nodes that are either (GPL-2.0+ OR MIT) or GPL-2.0-or-later. The drivers are GPL-2.0. I thought to follow the drivers. I see the example in [1] uses (GPL-2.0-only OR BSD-2-Clause). I see the crypto bindings that are converted to yaml are either (GPL-2.0-only OR BSD-2-Clause) or GPL-2.0-only. Is there another guideline that I miss? Thanks, ta [1] https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-schema.html
On 08/02/2022 15:40, Tudor.Ambarus@microchip.com wrote: > On 2/8/22 13:58, Krzysztof Kozlowski wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> On 08/02/2022 11:49, Tudor Ambarus wrote: >>> Convert Atmel AES documentation to yaml format. With the conversion the >>> clock and clock-names properties are made mandatory. The driver returns >>> -EINVAL if "aes_clk" is not found, reflect that in the bindings and make >>> the clock and clock-names properties mandatory. Update the example to >>> better describe how one should define the dt node. >>> >>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> >>> --- >>> .../crypto/atmel,at91sam9g46-aes.yaml | 65 +++++++++++++++++++ >>> .../bindings/crypto/atmel-crypto.txt | 20 ------ >>> 2 files changed, 65 insertions(+), 20 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml >>> >> >> I understand that you keep the license GPL-2.0 (not recommended mix) >> because of example coming from previous bindings or from DTS (both GPL-2.0)? >> > > The previous bindings did not have a license specified. We have DTS files with > these nodes that are either (GPL-2.0+ OR MIT) or GPL-2.0-or-later. The drivers > are GPL-2.0. I thought to follow the drivers. I see the example in [1] uses > (GPL-2.0-only OR BSD-2-Clause). I see the crypto bindings that are converted > to yaml are either (GPL-2.0-only OR BSD-2-Clause) or GPL-2.0-only. Is there > another guideline that I miss? > Yes, there is. Run checkpatch (your question kinds of point to the fact that you did not run it...): WARNING: DT binding documents should be licensed (GPL-2.0-only OR BSD-2-Clause) If your new bindings use copied/derivative description or DTS code which is licensed as only GPL-2.0, the bindings itself as derivative work might need to stay as GPL-2.0 as well. Unless copyright holders agree to re-license this as GPL2-OR-BSD. As representing company, your patch might be enough to re-license, but maybe other people contributed. I don't know. I just wanted to be sure that you use GPL-2.0 in purpose, because GPL2-OR-BSD cannot be used. Best regards, Krzysztof
On 2/8/22 16:55, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 08/02/2022 15:40, Tudor.Ambarus@microchip.com wrote: >> On 2/8/22 13:58, Krzysztof Kozlowski wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> On 08/02/2022 11:49, Tudor Ambarus wrote: >>>> Convert Atmel AES documentation to yaml format. With the conversion the >>>> clock and clock-names properties are made mandatory. The driver returns >>>> -EINVAL if "aes_clk" is not found, reflect that in the bindings and make >>>> the clock and clock-names properties mandatory. Update the example to >>>> better describe how one should define the dt node. >>>> >>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> >>>> --- >>>> .../crypto/atmel,at91sam9g46-aes.yaml | 65 +++++++++++++++++++ >>>> .../bindings/crypto/atmel-crypto.txt | 20 ------ >>>> 2 files changed, 65 insertions(+), 20 deletions(-) >>>> create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml >>>> >>> >>> I understand that you keep the license GPL-2.0 (not recommended mix) >>> because of example coming from previous bindings or from DTS (both GPL-2.0)? >>> >> >> The previous bindings did not have a license specified. We have DTS files with >> these nodes that are either (GPL-2.0+ OR MIT) or GPL-2.0-or-later. The drivers >> are GPL-2.0. I thought to follow the drivers. I see the example in [1] uses >> (GPL-2.0-only OR BSD-2-Clause). I see the crypto bindings that are converted >> to yaml are either (GPL-2.0-only OR BSD-2-Clause) or GPL-2.0-only. Is there >> another guideline that I miss? >> > > Yes, there is. Run checkpatch (your question kinds of point to the fact > that you did not run it...): > WARNING: DT binding documents should be licensed (GPL-2.0-only OR > BSD-2-Clause) Right. I usually run checkpatch --strict, but this warning slipped somehow. Maybe because of the two other false positives, too much noise. > > > If your new bindings use copied/derivative description or DTS code which > is licensed as only GPL-2.0, the bindings itself as derivative work > might need to stay as GPL-2.0 as well. Unless copyright holders agree to > re-license this as GPL2-OR-BSD. As representing company, your patch > might be enough to re-license, but maybe other people contributed. I > don't know. > > I just wanted to be sure that you use GPL-2.0 in purpose, because > GPL2-OR-BSD cannot be used. Ok, thanks for the explanation. I have to admit I'm not too familiar with the contents of each license. Will read them and come back with a follow up. ta
On 2/8/22 17:27, Tudor.Ambarus@microchip.com wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 2/8/22 16:55, Krzysztof Kozlowski wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> On 08/02/2022 15:40, Tudor.Ambarus@microchip.com wrote: >>> On 2/8/22 13:58, Krzysztof Kozlowski wrote: >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>> >>>> On 08/02/2022 11:49, Tudor Ambarus wrote: >>>>> Convert Atmel AES documentation to yaml format. With the conversion the >>>>> clock and clock-names properties are made mandatory. The driver returns >>>>> -EINVAL if "aes_clk" is not found, reflect that in the bindings and make >>>>> the clock and clock-names properties mandatory. Update the example to >>>>> better describe how one should define the dt node. >>>>> >>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> >>>>> --- >>>>> .../crypto/atmel,at91sam9g46-aes.yaml | 65 +++++++++++++++++++ >>>>> .../bindings/crypto/atmel-crypto.txt | 20 ------ >>>>> 2 files changed, 65 insertions(+), 20 deletions(-) >>>>> create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml >>>>> >>>> >>>> I understand that you keep the license GPL-2.0 (not recommended mix) >>>> because of example coming from previous bindings or from DTS (both GPL-2.0)? >>>> >>> >>> The previous bindings did not have a license specified. We have DTS files with >>> these nodes that are either (GPL-2.0+ OR MIT) or GPL-2.0-or-later. The drivers >>> are GPL-2.0. I thought to follow the drivers. I see the example in [1] uses >>> (GPL-2.0-only OR BSD-2-Clause). I see the crypto bindings that are converted >>> to yaml are either (GPL-2.0-only OR BSD-2-Clause) or GPL-2.0-only. Is there >>> another guideline that I miss? >>> >> >> Yes, there is. Run checkpatch (your question kinds of point to the fact >> that you did not run it...): >> WARNING: DT binding documents should be licensed (GPL-2.0-only OR >> BSD-2-Clause) > > Right. I usually run checkpatch --strict, but this warning slipped somehow. > Maybe because of the two other false positives, too much noise. >> >> >> If your new bindings use copied/derivative description or DTS code which >> is licensed as only GPL-2.0, the bindings itself as derivative work >> might need to stay as GPL-2.0 as well. Unless copyright holders agree to >> re-license this as GPL2-OR-BSD. As representing company, your patch >> might be enough to re-license, but maybe other people contributed. I >> don't know. >> >> I just wanted to be sure that you use GPL-2.0 in purpose, because >> GPL2-OR-BSD cannot be used. > > Ok, thanks for the explanation. I have to admit I'm not too familiar with > the contents of each license. Will read them and come back with a follow up. > Did some documentation work, and yes, we can use the recommended bindings license: (GPL-2.0-only OR BSD-2-Clause). Will resubmit. Thanks, Krzysztof! ta
diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml new file mode 100644 index 000000000000..146ff9c7b60e --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/atmel,at91sam9g46-aes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Advanced Encryption Standard (AES) HW cryptographic accelerator + +maintainers: + - Tudor Ambarus <tudor.ambarus@microchip.com> + +properties: + compatible: + const: atmel,at91sam9g46-aes + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: aes_clk + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + + aes: crypto@f8038000 { + compatible = "atmel,at91sam9g46-aes"; + reg = <0xe1810000 0x100>; + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 27>; + clock-names = "aes_clk"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(1)>, + <&dma0 AT91_XDMAC_DT_PERID(2)>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt index f2aab3dc2b52..1353ebd0dcaa 100644 --- a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt +++ b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt @@ -2,26 +2,6 @@ These are the HW cryptographic accelerators found on some Atmel products. -* Advanced Encryption Standard (AES) - -Required properties: -- compatible : Should be "atmel,at91sam9g46-aes". -- reg: Should contain AES registers location and length. -- interrupts: Should contain the IRQ line for the AES. -- dmas: List of two DMA specifiers as described in - atmel-dma.txt and dma.txt files. -- dma-names: Contains one identifier string for each DMA specifier - in the dmas property. - -Example: -aes@f8038000 { - compatible = "atmel,at91sam9g46-aes"; - reg = <0xf8038000 0x100>; - interrupts = <43 4 0>; - dmas = <&dma1 2 18>, - <&dma1 2 19>; - dma-names = "tx", "rx"; - * Triple Data Encryption Standard (Triple DES) Required properties:
Convert Atmel AES documentation to yaml format. With the conversion the clock and clock-names properties are made mandatory. The driver returns -EINVAL if "aes_clk" is not found, reflect that in the bindings and make the clock and clock-names properties mandatory. Update the example to better describe how one should define the dt node. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> --- .../crypto/atmel,at91sam9g46-aes.yaml | 65 +++++++++++++++++++ .../bindings/crypto/atmel-crypto.txt | 20 ------ 2 files changed, 65 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml