linux-kernel - Re: [RFC v2 1/2] clk: hisilicon: add CRG driver Hi3521a SoC

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220603112227.hmzwy7xxl6ddezqh@proprietary-killer>
Date:   Fri, 3 Jun 2022 06:22:27 -0500
From:   "Marty E. Plummer" <hanetzer@...rtmail.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     arnd@...db.de, cai.huoqing@...ux.dev, christian.koenig@....com,
        devicetree@...r.kernel.org, gengdongjiu@...wei.com,
        krzysztof.kozlowski+dt@...aro.org,
        linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
        linux@...linux.org.uk, michael@...le.cc, miquel.raynal@...tlin.com,
        mturquette@...libre.com, novikov@...ras.ru, olof@...om.net,
        p.yadav@...com, rdunlap@...radead.org, richard@....at,
        robh+dt@...nel.org, sboyd@...nel.org, soc@...nel.org,
        sumit.semwal@...aro.org, tudor.ambarus@...rochip.com,
        vigneshr@...com, xuwei5@...ilicon.com
Subject: Re: [RFC v2 1/2] clk: hisilicon: add CRG driver Hi3521a SoC

On Thu, Jun 02, 2022 at 08:37:43AM +0200, Krzysztof Kozlowski wrote:
> On 01/06/2022 20:24, Marty E. Plummer wrote:
> 
> >>> Either or. Whatever makes the workload easier is what I'm looking for.
> >>
> >> Sorry, you need to be more specific. Apply is not a job for you, for the
> >> patch submitter.
> >>
> >> Then you miss here important piece - which is the first patch. DTS goes
> >> always via separate branch (or even tree) from driver changes. That's
> >> why bindings are always separate first patches.
> >>
> > So, add a 4: arch/arm/boot/dts/soc.dtsi and 5: arch/arm/boot/dts/board.dts
> > to the above list, or should those be the same patch as well?
> 
> For me does not matter, sub architecture maintainer might have preference.
> 
Fair enough. That being said, for the dt-bindings patch, is it
permissible to include #define CLOCK_FOO 1337 and so on for clocks which
haven't been wired up in the driver yet? As in, you know they're there,
and are important enough to model, but you haven't gotten to that point
yet?
> Best regards,
> Krzysztof