[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2018479.PYKUYFuaPT@workhorse>
Date: Mon, 20 Oct 2025 15:56:39 +0200
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Conor Dooley <conor@...nel.org>
Cc: Alim Akhtar <alim.akhtar@...sung.com>, Avri Altman <avri.altman@....com>,
Bart Van Assche <bvanassche@....org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Chunfeng Yun <chunfeng.yun@...iatek.com>, Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Peter Wang <peter.wang@...iatek.com>, Stanley Jhu <chu.stanley@...il.com>,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Louis-Alexis Eyraud <louisalexis.eyraud@...labora.com>, kernel@...labora.com,
linux-scsi@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-phy@...ts.infradead.org
Subject:
Re: [PATCH v2 1/5] dt-bindings: ufs: mediatek,ufs: Add mt8196-ufshci variant
On Monday, 20 October 2025 15:27:40 Central European Summer Time Nicolas Frattaroli wrote:
> On Saturday, 18 October 2025 23:30:17 Central European Summer Time Conor Dooley wrote:
> > On Fri, Oct 17, 2025 at 09:02:07PM +0200, Nicolas Frattaroli wrote:
> > > On Friday, 17 October 2025 17:42:10 Central European Summer Time Conor Dooley wrote:
> > > > On Thu, Oct 16, 2025 at 02:06:43PM +0200, Nicolas Frattaroli wrote:
> > >
> > > > > +
> > > > > + freq-table-hz: true
> > > >
> > > > Then you add this deprecated property, which isn't mentioned in the
> > > > commit message and I don't see why a deprecated property is needed.
> > >
> > > I'll rework it to use operating-points-v2 instead. It needs one of
> > > the two, or else on mt8196 at least, the hardware locks up.
> > >
> > > I'll still add operating-points-v2 for all SoCs though, if that's
> > > okay with you.
> >
> > Right. I'd accept freq-table-hz if the other devices here have been
> > using it all along, but if this is something new - then please use the
> > operating-points-v2 property. Looking at the binding example, it looks
> > like it does indeed use freq-table-hz, so that's probably justification
> > enough to keep doing so.
>
> Turns out the only usage of freq-table-hz is in the examples I've added.
> Mainline does not at all have any nodes in the DT right now that would
> use this property.
>
> Ergo, I think I will go for operating-points-v2. We might as well clean
> this up now instead of ossifying a deprecated property in a new binding
> for the sake of downstream compatibility (which should never be a concern)
> that I am already breaking. The added benefit is that if we ever do get
> better OPP definitions than just two clock states, then we can actually
> add the OPP bandwidth properties so implementations can make informed
> decisions.
>
Nevermind, I see the existing binding had it in the example for 8183,
just not in the binding itself. So freq-table-hz it is.
Powered by blists - more mailing lists