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

Michael Walle
2022-05-03T13:43:45Z

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.

-michael