linux-kernel - Re: [PATCH v3 0/9] nvmem: sfp: binding updates and additions

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: <8602f6adb0fcf591e2923c736b345abd@walle.cc>
Date:   Mon, 09 May 2022 10:28:09 +0200
From:   Michael Walle <michael@...le.cc>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Sean Anderson <sean.anderson@...o.com>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        Li Yang <leoyang.li@....com>, linux-kernel@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH v3 0/9] nvmem: sfp: binding updates and additions

Am 2022-05-03 15:43, schrieb Michael Walle:
> Am 2022-04-29 17:56, schrieb Srinivas Kandagatla:
>> On 28/04/2022 19:16, Sean Anderson wrote:
>>> This adds several properties to the Layerscape Security Fuse 
>>> Processor
>>> (SFP) necessary for writing. Although the Linux driver does not use
>>> these bindings, I plan to use them in U-Boot [1]. It also adds a new
>>> compatibles for Trust Architecture (TA) 2.1 devices. In addition, it
>>> also adds an SFP binding for all TA 2.1 and 3.0 devices.
>>> 
>>> I would like to get this series merged for 5.18. As noted in patch 2,
>>> making the clock property mandatory is not an ABI break, but if this 
>>> is
>>> not applied then it would become an ABI break. The absolute minimum
>>> patches to apply for this would be patches 2 and 5. The rest 
>>> (including
>>> the regmap changes) could be deferred if necessary.
>>> 
>>> [1] 
>>> https://lore.kernel.org/u-boot/7c8e206a-cd40-2a77-6282-7f4bead2b13a@seco.com/T/#m591f8425b6f096ab3d54e6f7bd258e41cfa4c43b
>>> 
>>> Changes in v3:
>>> - Update commit message to note that this binding has not yet been
>>>    present in a relase, so it is OK to make otherwise breaking 
>>> changes.
>>> 
>>> Changes in v2:
>>> - Mention "regulator" in the description for ta-prog-sfp-supply
>>> - Convert sfp driver to use regmap
>>> - Fix various typos in commit messages
>>> 
>>> Sean Anderson (9):
>>>    dt-bindings: nvmem: sfp: Fix typo
>>>    dt-bindings: nvmem: sfp: Add clock properties
>>>    dt-bindings: nvmem: sfp: Add TA_PROG_SFP supply
>>>    dt-bindings: nvmem: sfp: Add compatible binding for TA 2.1 SFPs
>>>    arm64: dts: ls1028a: Update SFP binding to include clock
>>>    ARM: dts: layerscape: Add SFP binding for TA 2.1 devices
>>>    ARM: dts: Add SFP binding for TA 3.0 devices
>>>    nvmem: sfp: Use regmap
>>>    nvmem: sfp: Add support for TA 2.1 devices
>>> 
>> 
>> I have applied all the patches except 5/9, 6/9, and 7/9 dts patches
>> which need to go via dts maintainer tree.
> 
> Ahh. At least the device tree binding change (and the device tree
> changes itself) should be applied as fixes for the 5.18 release,
> so we don't have any conflicting descriptions. My fixes tag was never
> picked up, unfortunately:
> https://lore.kernel.org/linux-devicetree/4a45db184fbadc278624571dfbeb5004@walle.cc/
> 
> Srinivas, I've seen you picked it up into your for-next branch.
> Can we fix that?
> 
> I'd guess the layerscape device tree change also need a Fixes: tag.

Ping. We are now -rc7 :/

-michael