linux-kernel - Re: [PATCH v6 0/4] dt-bindings: qcom-qce: Convert bindings to yaml & related changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 20 Sep 2022 14:43:12 +0530
From:   Bhupesh Sharma <bhupesh.sharma@...aro.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, agross@...nel.org,
        linux-kernel@...r.kernel.org, robh+dt@...nel.org,
        thara.gopinath@...il.com, devicetree@...r.kernel.org,
        robh@...nel.org, andersson@...nel.org, bhupesh.linux@...il.com,
        Jordan Crouse <jorcrous@...zon.com>
Subject: Re: [PATCH v6 0/4] dt-bindings: qcom-qce: Convert bindings to yaml &
 related changes

On Tue, 20 Sept 2022 at 14:24, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.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