[<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