Re: [PATCH 01/11] dt-bindings: crypto: qcom,ice: Require power-domain and iface clk
From: Manivannan Sadhasivam
Date: Tue Mar 03 2026 - 11:59:29 EST
On Fri, Feb 20, 2026 at 09:59:41AM -0600, Bjorn Andersson wrote:
> On Fri, Feb 20, 2026 at 08:01:59PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Feb 09, 2026 at 11:13:06AM +0530, Harshal Dev wrote:
> > > On 2/6/2026 4:20 PM, Krzysztof Kozlowski wrote:
> > > > On 06/02/2026 11:07, Harshal Dev wrote:
> > > >> On 2/5/2026 4:47 PM, Krzysztof Kozlowski wrote:
> > > >>> On 03/02/2026 10:26, Harshal Dev wrote:
> > > >>>> On 1/26/2026 3:59 PM, Konrad Dybcio wrote:
> > > >>>>> On 1/23/26 12:04 PM, Harshal Dev wrote:
> > > >>>>>> On 1/23/2026 2:27 PM, Krzysztof Kozlowski wrote:
> > > >>>>>>> On 23/01/2026 08:11, Harshal Dev wrote:
> [..]
> > > >>> My NAK for driver change stays. This is wrong approach - you cannot
> > > >>> break working DTS.
> > > >>>
> > > >>
> > > >> I agree that this patch in it's current form will break both the in-kernel and
> > > >> out of tree DTS written in accordance with the old binding. If this isn't acceptable
> > > >
> > > > What? You just said few lines above:
> > > > "it will still continue to work if:"
> > > >
> > >
> > > I hope I am clear now, 'it' referred to the in-tree ICE driver and not to this particular
> > > DT schema commit. :)
> > >
> > > > So either this will continue to work or not. I don't understand this
> > > > thread and honestly do not have patience for it. I gave you already
> > > > reasoning what is wrong and why it is. Now it is just wasting my time.
> > > >
> > >
> > > Apologies again for the confusion. I totally agree, as replied previously too, that the
> > > updated DT binding breaks backward compatibility. Like I said, I will post another patch
> > > to preserve the correctness of existing in-tree and out-of-tree DTS.
> > >
> >
> > The ICE hardware cannot work without 'iface' clock and the power domain, which
> > are shared with the UFS PHY. One can argue that ICE is actually a part of the
> > peripherals like UFS/eMMC, but I don't have access to internal layout, so cannot
> > comment on that. I ran into this issue today when I tried to rmmod ice driver
> > together with ufs_qcom driver and got SError when reloading the module because
> > ice driver was trying to access unclocked/unpowered register.
> >
> > But you should mark the resources as 'required' in the binding and justify the
> > ABI break. No need to preserve backwards compatibility here as the binding was
> > wrong from day one.
> >
>
> Marking it "required" in the binding, implies that it's fine for the
> driver to fail in its absence. If I understand correctly that will
> prevent UFS and eMMC from probing, unless you have a DTB from "the
> future".
>
> Even if I merge the dt-binding change through the qcom-tree (together
> with the driver change) I will not guarantee that torvalds/master will
> remain bisectable - because dts changes and driver changes goes in
> different branches.
>
Yeah, that's true.
>
> As such, the pragmatic approach is to introduce the clock as optional
> and then once we're "certain" that the dts changes has propagated we
> can consider breaking the backwards compatibility.
>
Only if we remember to mark it required some point, fine with me!
- Mani
--
மணிவண்ணன் சதாசிவம்