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] [day] [month] [year] [list]
Message-ID: <aFlW5zVERnpwIkS4@pluto>
Date: Mon, 23 Jun 2025 14:30:15 +0100
From: Cristian Marussi <cristian.marussi@....com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: Cristian Marussi <cristian.marussi@....com>, robh@...nel.org,
	krzk+dt@...nel.org, conor+dt@...nel.org, matthias.bgg@...il.com,
	sudeep.holla@....com, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, arm-scmi@...r.kernel.org,
	kernel@...labora.com
Subject: Re: [PATCH v1 0/2] firmware: Add MediaTek TinySYS SCMI Protocol

On Mon, Jun 23, 2025 at 02:32:24PM +0200, AngeloGioacchino Del Regno wrote:
> Il 23/06/25 14:17, Cristian Marussi ha scritto:
> > On Mon, Jun 23, 2025 at 02:01:34PM +0200, AngeloGioacchino Del Regno wrote:
> > > This series adds basic support for the MediaTek TinySYS SCMI Protocol,
> > > found on the MediaTek Dimensity 9200, 9300 and 9400, other than on the
> > > MT8196 Chromebook SoC.
> > > 
> > > This is used to communicate with the CM_MGR and other MCUs for power
> > > management purposes.
> > 
> > Hi Angelo,
> > 
> > thanks for this.
> > 
> > I will do a proper review in the coming days of this series anyway, but
> > upfront for future V2:
> > 
> > - you should provide some sort of documentation for this new
> >    vendor protocol and its messages, as an example from IMX:
> > 
> > 	drivers/firmware/arm_scmi/vendors/imx/imx95.rst
> 
> Noted.
> 
> > 
> > - where is the SCMI driver that will call all the new vendor ops
> >    defined in: scmi_mtk_protocol.h ?
> 
> This was tested with code that is not clean at all (hence I can't push it upstream)
> and well... I didn't think about the fact that, effectively, without an user, this
> code ends up being unused.
> 
> I can't promise to send a clean user in this cycle, but I would really appreciate
> if you could still check the protocol code, so that if there's anything that you
> can spot I can fix it while the rest gets done :-)

Sure, I will anyway review, but a driver user exampe would be useful, maybe
posting it at the end of the series as a NOT-FOR-UPSTREAM/RFC (something like that)
so that we can have an iddea of the usage patterns while being aware that it is
still not clean for upstream.

Thanks,
Cristian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ