linux-kernel - Re: [PATCH v4 5/5] clk: scmi: Support Spread Spectrum for NXP i.MX95

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: <20250924-versed-auspicious-bullmastiff-19de2e@sudeepholla>
Date: Wed, 24 Sep 2025 13:59:56 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Cristian Marussi <cristian.marussi@....com>
Cc: Sebin Francis <sebin.francis@...com>, Peng Fan <peng.fan@....com>,
	Michael Turquette <mturquette@...libre.com>,
	Sudeep Holla <sudeep.holla@....com>,
	Stephen Boyd <sboyd@...nel.org>,
	Marco Felsch <m.felsch@...gutronix.de>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Brian Masney <bmasney@...hat.com>, Dhruva Gole <d-gole@...com>,
	Dan Carpenter <dan.carpenter@...aro.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arm-scmi@...r.kernel.org" <arm-scmi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v4 5/5] clk: scmi: Support Spread Spectrum for NXP i.MX95

Hi Cristian,

On Wed, Sep 24, 2025 at 01:40:56PM +0100, Cristian Marussi wrote:
> On Wed, Sep 24, 2025 at 05:45:32PM +0530, Sebin Francis wrote:
> > Hi Peng,
> 
> Hi ,
> 
> > 
> > On 24/09/25 17:13, Peng Fan wrote:
> > > > Subject: Re: [PATCH v4 5/5] clk: scmi: Support Spread Spectrum for
> > > > NXP i.MX95
> > > ...
> > > > > > >         SCMI_CLOCK_CFG_OEM_START = 0x80,
> > > > > > > +     SCMI_CLOCK_CFG_IMX_SSC = 0x80,
> > > > > > 
> > > > > > TI is also planning to implement the same in our upcoming platform.
> > > > > > so can we use a generic ID instead of vender specfic message ID?
> > > > > 
> > > > > I tried to push to new generic ID [1] in half a year ago, but in the
> > > > > end ARM decided not to add generic ID for spread spectrum support.
> > > > > 
> > > > > To i.MX, it is too late to use a generic ID and waiting spec, i.MX
> > > > > firmware has been public for quite some time and passed several
> > > > external releases.
> > > > > So I need to use what our firmware adds and spec allows: vendor
> > > > > extension.
> > > > 
> > > > Thanks for the quick response,
> > > > Since this implementation is specific to i.MX, can you move this to a
> > > > vendor specific file, so that it will not break i.MX's firmware and TI can
> > > > implement SSC in TI specific file.
> > > 
> > > i.MX has encountered issue with pinctrl-scmi.c and pinctrl-imx-scmi.c
> > > both supports SCMI PINCTRL. Current linux scmi does not support
> > > both drivers built in kernel image, because scmi devlink issue.
> > >
> 
> Yes indeed, BUT the vendor protocol extensions mechanism was meant to
> serve the development of vendor custom protocols and drivers, it was
> NEVER meant really to allow multiple alternative drivers implementation
> on top of the same standard protocols like it happened with pinctrl-imx-scmi...
>  
> > > Sudeep said he would address the devlink issue in 6.19 cycle.
> > > 
> > > Given the current situation, I'm hesitant to introduce a new driver
> > > saying clk-imx-scmi.c.
> > >
> 
> Even if the devlink issues will be solved, in THIS case the problem is
> handling custom vendor extensions inside a standard protocol, as it is
> allowed in this case...
> 
> > > What I'm unclear about is whether moving to a vendor-specific file
> > > implies creating a new driver (i.e., clk-imx-scmi.c), or if it could be
> > > handled via a callback or another mechanism. Could you help
> > > clarify the intended direction?
> > 
> > My intended was to handle it via callback or something similar, so that TI
> > can its own callback for the TI's SSC implementation.
> > 
> 
> This is exactly what is needed, the ability to extend with vendor
> extensions callback the behavior of a standard protocol where
> allowed....this is NOT currently supported and sincerely that was the
> reason months ago I proposed initially that maybe we could have standardized
> a new common clock extension SSC instead of using the OEM extensions since:
> 
> 1. it seemed a pretty generic operation
> 2. any per-vendor extension callback of std protocol was NOT ready :P
> 
> ...then this proposal never went anywhere with ATG...AND now looking at
> this thread I think that it is good at the end that we did NOT add a new
> standard extended clock config instead of the IMX OEM, since now it
> seems that TI wants its own non-compatible implementation...
> 
> So yes the ideal solutiomn would be to extend in a generic way the SCMI
> framework so that you can add in these cases custom handling of vendor
> extensions for standard protocols (and then generalize the current
> clk-scmi IMX support and add the new TI one...)...but I have not thought
> about this and I certainly dont have enough bandwidth now to work on
> this...beside having already in the pipeline other stuff/fixes like
> a proper fix for vendor drivers coex like Peng askes (rightly so a few
> months ago)
> 

Thanks for the detailed response as usual 😄. I don't have much to add
in case anyone is expecting different or more info from me.

-- 
Regards,
Sudeep