[PATCH v3 0/9] nvmem: sfp: binding updates and additions

[Michael Walle]

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