mbox series

[v6,0/4] dt-bindings: qcom-qce: Convert bindings to yaml & related changes

Message ID 20220919220804.1047292-1-bhupesh.sharma@linaro.org (mailing list archive)
Headers show
Series dt-bindings: qcom-qce: Convert bindings to yaml & related changes | expand

Message

Bhupesh Sharma Sept. 19, 2022, 10:08 p.m. UTC
Changes since v5:
=================
- v5 can be seen here: https://lore.kernel.org/lkml/20211110105922.217895-1-bhupesh.sharma@linaro.org/
- As per Bjorn's suggestion on irc, broke down the patchset into 4
  separate patchsets, one each for the following areas to allow easier
  review and handling from the respective maintainer(s):
        'arm-msm', 'crypto', 'dma' and 'devicetree'
  This patchset is directed for the 'arm-msm' tree / area.
- Addressed Rob's, Vladimir's and Bjorn's review comments on v5.
- Added Tested-by from Jordan received on the v5.
- Also added a 'defconfig' change where I enabled the QCE block as a module.

Changes since v4:
=================
- v4 for sm8250 can be seen here: https://lore.kernel.org/linux-arm-msm/20211013105541.68045-1-bhupesh.sharma@linaro.org/
- v1 for sm8150 qce enablement can be seen here: https://lore.kernel.org/linux-arm-msm/20211013165823.88123-1-bhupesh.sharma@linaro.org/
- Merged the sm8150 and sm8250 enablement patches in the same patchset,
  as per suggestions from Bjorn.
- Dropped a couple of patches from v4, as these have been picked by
  Bjorn already via his tree.
- Addressed review comments from Vladimir, Thara and Rob.
- Collect Reviewed-by from Rob and Thara on some of the patches from the
  v4 patchset.

Changes since v3:
=================
- v3 can be seen here: https://lore.kernel.org/linux-arm-msm/20210519143700.27392-1-bhupesh.sharma@linaro.org/
- Dropped a couple of patches from v3, on basis of the review comments:
   ~ [PATCH 13/17] crypto: qce: core: Make clocks optional
   ~ [PATCH 15/17] crypto: qce: Convert the device found dev_dbg() to dev_info()
- Addressed review comments from Thara, Rob and Stephan Gerhold.
- Collect Reviewed-by from Rob and Thara on some of the patches from the
  v3 patchset.

Changes since v2:
=================
- v2 can be seen here: https://lore.kernel.org/dmaengine/20210505213731.538612-1-bhupesh.sharma@linaro.org/
- Drop a couple of patches from v1, which tried to address the defered
  probing of qce driver in case bam dma driver is not yet probed.
  Replace it instead with a single (simpler) patch [PATCH 16/17].
- Convert bam dma and qce crypto dt-bindings to YAML.
- Addressed review comments from Thara, Bjorn, Vinod and Rob.

Changes since v1:
=================
- v1 can be seen here: https://lore.kernel.org/linux-arm-msm/20210310052503.3618486-1-bhupesh.sharma@linaro.org/ 
- v1 did not work well as reported earlier by Dmitry, so v2 contains the following
  changes/fixes:
  ~ Enable the interconnect path b/w BAM DMA and main memory first
    before trying to access the BAM DMA registers.
  ~ Enable the interconnect path b/w qce crytpo and main memory first
    before trying to access the qce crypto registers.
  ~ Make sure to document the required and optional properties for both
    BAM DMA and qce crypto drivers.
  ~ Add a few debug related print messages in case the qce crypto driver
    passes or fails to probe.
  ~ Convert the qce crypto driver probe to a defered one in case the BAM DMA
    or the interconnect driver(s) (needed on specific Qualcomm parts) are not
    yet probed.

Qualcomm crypto engine (qce) is available on several Snapdragon SoCs.
The qce block supports hardware accelerated algorithms for encryption
and authentication. It also provides support for aes, des, 3des
encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
authentication algorithms.

Note that this patchset is dependent on the dt-bindings patchset (see [1]) sent to devicetree list.

[1]. https://lore.kernel.org/linux-arm-msm/20220919195618.926227-1-bhupesh.sharma@linaro.org/

Cc: thara.gopinath@gmail.com
Cc: robh@kernel.org
Cc: andersson@kernel.org
Tested-by: Jordan Crouse <jorcrous@amazon.com>

Bhupesh Sharma (4):
  ARM: dts: qcom: Use new compatibles for crypto nodes
  arm64: dts: qcom: sm8250: Add dt entries to support crypto engine.
  arm64: dts: qcom: sm8150: Add dt entries to support crypto engine.
  arm64: defconfig: Enable Qualcomm QCE crypto

 arch/arm/boot/dts/qcom-ipq4019.dtsi   |  2 +-
 arch/arm64/boot/dts/qcom/ipq6018.dtsi |  2 +-
 arch/arm64/boot/dts/qcom/ipq8074.dtsi |  2 +-
 arch/arm64/boot/dts/qcom/msm8996.dtsi |  2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi  |  2 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi  | 28 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8250.dtsi  | 28 +++++++++++++++++++++++++++
 arch/arm64/configs/defconfig          |  1 +
 8 files changed, 62 insertions(+), 5 deletions(-)

Comments

Bhupesh Sharma Sept. 19, 2022, 10:11 p.m. UTC | #1
On Tue, 20 Sept 2022 at 03:38, Bhupesh Sharma <bhupesh.sharma@linaro.org> wrote:
>
> Changes since v5:
> =================
> - v5 can be seen here: https://lore.kernel.org/lkml/20211110105922.217895-1-bhupesh.sharma@linaro.org/
> - As per Bjorn's suggestion on irc, broke down the patchset into 4
>   separate patchsets, one each for the following areas to allow easier
>   review and handling from the respective maintainer(s):
>         'arm-msm', 'crypto', 'dma' and 'devicetree'
>   This patchset is directed for the 'arm-msm' tree / area.
> - Addressed Rob's, Vladimir's and Bjorn's review comments on v5.
> - Added Tested-by from Jordan received on the v5.
> - Also added a 'defconfig' change where I enabled the QCE block as a module.
>
> Changes since v4:
> =================
> - v4 for sm8250 can be seen here: https://lore.kernel.org/linux-arm-msm/20211013105541.68045-1-bhupesh.sharma@linaro.org/
> - v1 for sm8150 qce enablement can be seen here: https://lore.kernel.org/linux-arm-msm/20211013165823.88123-1-bhupesh.sharma@linaro.org/
> - Merged the sm8150 and sm8250 enablement patches in the same patchset,
>   as per suggestions from Bjorn.
> - Dropped a couple of patches from v4, as these have been picked by
>   Bjorn already via his tree.
> - Addressed review comments from Vladimir, Thara and Rob.
> - Collect Reviewed-by from Rob and Thara on some of the patches from the
>   v4 patchset.
>
> Changes since v3:
> =================
> - v3 can be seen here: https://lore.kernel.org/linux-arm-msm/20210519143700.27392-1-bhupesh.sharma@linaro.org/
> - Dropped a couple of patches from v3, on basis of the review comments:
>    ~ [PATCH 13/17] crypto: qce: core: Make clocks optional
>    ~ [PATCH 15/17] crypto: qce: Convert the device found dev_dbg() to dev_info()
> - Addressed review comments from Thara, Rob and Stephan Gerhold.
> - Collect Reviewed-by from Rob and Thara on some of the patches from the
>   v3 patchset.
>
> Changes since v2:
> =================
> - v2 can be seen here: https://lore.kernel.org/dmaengine/20210505213731.538612-1-bhupesh.sharma@linaro.org/
> - Drop a couple of patches from v1, which tried to address the defered
>   probing of qce driver in case bam dma driver is not yet probed.
>   Replace it instead with a single (simpler) patch [PATCH 16/17].
> - Convert bam dma and qce crypto dt-bindings to YAML.
> - Addressed review comments from Thara, Bjorn, Vinod and Rob.
>
> Changes since v1:
> =================
> - v1 can be seen here: https://lore.kernel.org/linux-arm-msm/20210310052503.3618486-1-bhupesh.sharma@linaro.org/
> - v1 did not work well as reported earlier by Dmitry, so v2 contains the following
>   changes/fixes:
>   ~ Enable the interconnect path b/w BAM DMA and main memory first
>     before trying to access the BAM DMA registers.
>   ~ Enable the interconnect path b/w qce crytpo and main memory first
>     before trying to access the qce crypto registers.
>   ~ Make sure to document the required and optional properties for both
>     BAM DMA and qce crypto drivers.
>   ~ Add a few debug related print messages in case the qce crypto driver
>     passes or fails to probe.
>   ~ Convert the qce crypto driver probe to a defered one in case the BAM DMA
>     or the interconnect driver(s) (needed on specific Qualcomm parts) are not
>     yet probed.
>
> Qualcomm crypto engine (qce) is available on several Snapdragon SoCs.
> The qce block supports hardware accelerated algorithms for encryption
> and authentication. It also provides support for aes, des, 3des
> encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
> authentication algorithms.
>
> Note that this patchset is dependent on the dt-bindings patchset (see [1]) sent to devicetree list.
>
> [1]. https://lore.kernel.org/linux-arm-msm/20220919195618.926227-1-bhupesh.sharma@linaro.org/
>
> Cc: thara.gopinath@gmail.com
> Cc: robh@kernel.org
> Cc: andersson@kernel.org
> Tested-by: Jordan Crouse <jorcrous@amazon.com>
>
> Bhupesh Sharma (4):
>   ARM: dts: qcom: Use new compatibles for crypto nodes
>   arm64: dts: qcom: sm8250: Add dt entries to support crypto engine.
>   arm64: dts: qcom: sm8150: Add dt entries to support crypto engine.
>   arm64: defconfig: Enable Qualcomm QCE crypto
>
>  arch/arm/boot/dts/qcom-ipq4019.dtsi   |  2 +-
>  arch/arm64/boot/dts/qcom/ipq6018.dtsi |  2 +-
>  arch/arm64/boot/dts/qcom/ipq8074.dtsi |  2 +-
>  arch/arm64/boot/dts/qcom/msm8996.dtsi |  2 +-
>  arch/arm64/boot/dts/qcom/sdm845.dtsi  |  2 +-
>  arch/arm64/boot/dts/qcom/sm8150.dtsi  | 28 +++++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8250.dtsi  | 28 +++++++++++++++++++++++++++
>  arch/arm64/configs/defconfig          |  1 +
>  8 files changed, 62 insertions(+), 5 deletions(-)
>
> --
> 2.37.1

Please ignore this patchset as I made some typos in the cover-letter
while sending it out. I will send a revised version shortly.

Thanks,
Bhupesh
Krzysztof Kozlowski Sept. 20, 2022, 7:28 a.m. UTC | #2
On 20/09/2022 00:08, Bhupesh Sharma wrote:

(...)


> 
> Qualcomm crypto engine (qce) is available on several Snapdragon SoCs.
> The qce block supports hardware accelerated algorithms for encryption
> and authentication. It also provides support for aes, des, 3des
> encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
> authentication algorithms.
> 
> Note that this patchset is dependent on the dt-bindings patchset (see [1]) sent to devicetree list.
> 
> [1]. https://lore.kernel.org/linux-arm-msm/20220919195618.926227-1-bhupesh.sharma@linaro.org/

If it is dependent on the bindings only, keep them together. However I
don't think this is the only dependency. You add here several
compatibles which are not supported.

Best regards,
Krzysztof
Bhupesh Sharma Sept. 20, 2022, 8:48 a.m. UTC | #3
On 9/20/22 12:58 PM, Krzysztof Kozlowski wrote:
> On 20/09/2022 00:08, Bhupesh Sharma wrote:
> 
> (...)
> 
> 
>>
>> Qualcomm crypto engine (qce) is available on several Snapdragon SoCs.
>> The qce block supports hardware accelerated algorithms for encryption
>> and authentication. It also provides support for aes, des, 3des
>> encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
>> authentication algorithms.
>>
>> Note that this patchset is dependent on the dt-bindings patchset (see [1]) sent to devicetree list.
>>
>> [1]. https://lore.kernel.org/linux-arm-msm/20220919195618.926227-1-bhupesh.sharma@linaro.org/
> 
> If it is dependent on the bindings only, keep them together. However I
> don't think this is the only dependency. You add here several
> compatibles which are not supported.


Please go through the cover letter where I mentioned that:
   'As per Bjorn's suggestion on irc, broke down the patchset into 4
   separate patchsets, one each for the following areas to allow easier
   review and handling from the respective maintainer(s):
         'arm-msm', 'crypto', 'dma' and 'devicetree'
   This patchset is directed for the 'devicetree' tree / area.'

Basically now the patchset which had around 23 patches in v5 will send 
out as 4 separate patchsets one each for 'arm-msm', 'crypto', 'dma' and 
'devicetree' trees.

So when all the respective subsets are picked up, all the compatibles 
are in place.

Thanks,
Bhupesh
Krzysztof Kozlowski Sept. 20, 2022, 8:54 a.m. UTC | #4
On 20/09/2022 10:48, Bhupesh Sharma wrote:
> 
> On 9/20/22 12:58 PM, Krzysztof Kozlowski wrote:
>> On 20/09/2022 00:08, Bhupesh Sharma wrote:
>>
>> (...)
>>
>>
>>>
>>> Qualcomm crypto engine (qce) is available on several Snapdragon SoCs.
>>> The qce block supports hardware accelerated algorithms for encryption
>>> and authentication. It also provides support for aes, des, 3des
>>> encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
>>> authentication algorithms.
>>>
>>> Note that this patchset is dependent on the dt-bindings patchset (see [1]) sent to devicetree list.
>>>
>>> [1]. https://lore.kernel.org/linux-arm-msm/20220919195618.926227-1-bhupesh.sharma@linaro.org/
>>
>> If it is dependent on the bindings only, keep them together. However I
>> don't think this is the only dependency. You add here several
>> compatibles which are not supported.
> 
> 
> Please go through the cover letter where I mentioned that:
>    'As per Bjorn's suggestion on irc, broke down the patchset into 4
>    separate patchsets, one each for the following areas to allow easier
>    review and handling from the respective maintainer(s):
>          'arm-msm', 'crypto', 'dma' and 'devicetree'
>    This patchset is directed for the 'devicetree' tree / area.'
> 
> Basically now the patchset which had around 23 patches in v5 will send 
> out as 4 separate patchsets one each for 'arm-msm', 'crypto', 'dma' and 
> 'devicetree' trees.
> 
> So when all the respective subsets are picked up, all the compatibles 
> are in place.

and none of reviewers can find them, because you linked only bindings.
Keeping bindings separate from everything is not good approach. Either
they should be with DTS or with driver changes. Otherwise how can we
even look that they are matching DTS?

Keeping them separate even makes impression there are no ABI breaks and
bisectability issues...


Best regards,
Krzysztof
Bhupesh Sharma Sept. 20, 2022, 9:13 a.m. UTC | #5
On Tue, 20 Sept 2022 at 14:24, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 20/09/2022 10:48, Bhupesh Sharma wrote:
> >
> > On 9/20/22 12:58 PM, Krzysztof Kozlowski wrote:
> >> On 20/09/2022 00:08, Bhupesh Sharma wrote:
> >>
> >> (...)
> >>
> >>
> >>>
> >>> Qualcomm crypto engine (qce) is available on several Snapdragon SoCs.
> >>> The qce block supports hardware accelerated algorithms for encryption
> >>> and authentication. It also provides support for aes, des, 3des
> >>> encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
> >>> authentication algorithms.
> >>>
> >>> Note that this patchset is dependent on the dt-bindings patchset (see [1]) sent to devicetree list.
> >>>
> >>> [1]. https://lore.kernel.org/linux-arm-msm/20220919195618.926227-1-bhupesh.sharma@linaro.org/
> >>
> >> If it is dependent on the bindings only, keep them together. However I
> >> don't think this is the only dependency. You add here several
> >> compatibles which are not supported.
> >
> >
> > Please go through the cover letter where I mentioned that:
> >    'As per Bjorn's suggestion on irc, broke down the patchset into 4
> >    separate patchsets, one each for the following areas to allow easier
> >    review and handling from the respective maintainer(s):
> >          'arm-msm', 'crypto', 'dma' and 'devicetree'
> >    This patchset is directed for the 'devicetree' tree / area.'
> >
> > Basically now the patchset which had around 23 patches in v5 will send
> > out as 4 separate patchsets one each for 'arm-msm', 'crypto', 'dma' and
> > 'devicetree' trees.
> >
> > So when all the respective subsets are picked up, all the compatibles
> > are in place.
>
> and none of reviewers can find them, because you linked only bindings.
> Keeping bindings separate from everything is not good approach. Either
> they should be with DTS or with driver changes. Otherwise how can we
> even look that they are matching DTS?
>
> Keeping them separate even makes impression there are no ABI breaks and
> bisectability issues...

I see your point, but as I mentioned this was as per suggestions from
other maintainers only :)
Perhaps a good topic for the next LPC maintainers meetup - i.e. would
maintainers be more happy with subpatches for their specific area v/s
being cc'ed on a single patchset which touches other areas as well
(but are required for enabling a feature in its entirety).

Thanks,
Bhupesh