From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Roger Lu <roger.lu@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Enric Balletbo Serra <eballetbo@gmail.com>,
Kevin Hilman <khilman@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Nicolas Boichat <drinkcat@google.com>,
Stephen Boyd <sboyd@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: Fan Chen <fan.chen@mediatek.com>,
HenryC Chen <HenryC.Chen@mediatek.com>,
Xiaoqing Liu <Xiaoqing.Liu@mediatek.com>,
Charles Yang <Charles.Yang@mediatek.com>,
Angus Lin <Angus.Lin@mediatek.com>,
Mark Rutland <mark.rutland@arm.com>, Nishanth Menon <nm@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v22 5/7] soc: mediatek: SVS: add debug commands
Date: Mon, 31 Jan 2022 12:11:51 +0100 [thread overview]
Message-ID: <0846872b-03da-ee5d-6a9d-e6c9fa754191@collabora.com> (raw)
In-Reply-To: <20220127033956.24585-6-roger.lu@mediatek.com>
Il 27/01/22 04:39, Roger Lu ha scritto:
> The purpose of SVS is to help find the suitable voltages
> for DVFS. Therefore, if SVS bank voltages are concerned
> to be wrong, we can adjust SVS bank voltages by this patch.
>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Hello Roger,
I was thinking about what this patch is adding... and I have a few considerations.
It's nice to have a debugging mechanism to read the status and dump registers, as
that's very helpful when doing heavy debugging of the IP... but adding the
possibility to write a voltage offset may be very dangerous: think about the case
in which, either for misconfiguration, or for any other reason, the debugfs entry
that allows writing voffset becomes user-writable, or a user writes an impossibly
high voffset.
In case a very low (negative) voffset is entered, the platform would crash (denial
of service); if a very high voffset is entered, hardware damage may occur.
For this reason, there are two proposals:
1. If you want to keep the debugfs voffset write, please constrain the permissible
voffset to an acceptable range that at least makes it unlikely to damage the HW;
Moreover, since voffset write is a feature that would be used in very limited
debugging cases, I think that this should be implemented over a build-time
configuration barrier... something like CONFIG_MTK_SVS_DEBUG_ALLOW_WRITE, or
similar;
2. Since it's very unlikely for someone to really play that much with a voltage
offset during runtime, and since this looks like something very machine specific
(perhaps addressing board-specific quirks?), I would suggest to add this as a
device-tree parameter instead, such as "mediatek,svs-voffset", as it is indeed
possible to specify both positive or negative values in DT.
I would prefer proposal 2, as it looks generally cleaner and way less risky.
Regards,
Angelo
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Roger Lu <roger.lu@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Enric Balletbo Serra <eballetbo@gmail.com>,
Kevin Hilman <khilman@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Nicolas Boichat <drinkcat@google.com>,
Stephen Boyd <sboyd@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: Fan Chen <fan.chen@mediatek.com>,
HenryC Chen <HenryC.Chen@mediatek.com>,
Xiaoqing Liu <Xiaoqing.Liu@mediatek.com>,
Charles Yang <Charles.Yang@mediatek.com>,
Angus Lin <Angus.Lin@mediatek.com>,
Mark Rutland <mark.rutland@arm.com>, Nishanth Menon <nm@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v22 5/7] soc: mediatek: SVS: add debug commands
Date: Mon, 31 Jan 2022 12:11:51 +0100 [thread overview]
Message-ID: <0846872b-03da-ee5d-6a9d-e6c9fa754191@collabora.com> (raw)
In-Reply-To: <20220127033956.24585-6-roger.lu@mediatek.com>
Il 27/01/22 04:39, Roger Lu ha scritto:
> The purpose of SVS is to help find the suitable voltages
> for DVFS. Therefore, if SVS bank voltages are concerned
> to be wrong, we can adjust SVS bank voltages by this patch.
>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Hello Roger,
I was thinking about what this patch is adding... and I have a few considerations.
It's nice to have a debugging mechanism to read the status and dump registers, as
that's very helpful when doing heavy debugging of the IP... but adding the
possibility to write a voltage offset may be very dangerous: think about the case
in which, either for misconfiguration, or for any other reason, the debugfs entry
that allows writing voffset becomes user-writable, or a user writes an impossibly
high voffset.
In case a very low (negative) voffset is entered, the platform would crash (denial
of service); if a very high voffset is entered, hardware damage may occur.
For this reason, there are two proposals:
1. If you want to keep the debugfs voffset write, please constrain the permissible
voffset to an acceptable range that at least makes it unlikely to damage the HW;
Moreover, since voffset write is a feature that would be used in very limited
debugging cases, I think that this should be implemented over a build-time
configuration barrier... something like CONFIG_MTK_SVS_DEBUG_ALLOW_WRITE, or
similar;
2. Since it's very unlikely for someone to really play that much with a voltage
offset during runtime, and since this looks like something very machine specific
(perhaps addressing board-specific quirks?), I would suggest to add this as a
device-tree parameter instead, such as "mediatek,svs-voffset", as it is indeed
possible to specify both positive or negative values in DT.
I would prefer proposal 2, as it looks generally cleaner and way less risky.
Regards,
Angelo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Roger Lu <roger.lu@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Enric Balletbo Serra <eballetbo@gmail.com>,
Kevin Hilman <khilman@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Nicolas Boichat <drinkcat@google.com>,
Stephen Boyd <sboyd@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: Fan Chen <fan.chen@mediatek.com>,
HenryC Chen <HenryC.Chen@mediatek.com>,
Xiaoqing Liu <Xiaoqing.Liu@mediatek.com>,
Charles Yang <Charles.Yang@mediatek.com>,
Angus Lin <Angus.Lin@mediatek.com>,
Mark Rutland <mark.rutland@arm.com>, Nishanth Menon <nm@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v22 5/7] soc: mediatek: SVS: add debug commands
Date: Mon, 31 Jan 2022 12:11:51 +0100 [thread overview]
Message-ID: <0846872b-03da-ee5d-6a9d-e6c9fa754191@collabora.com> (raw)
In-Reply-To: <20220127033956.24585-6-roger.lu@mediatek.com>
Il 27/01/22 04:39, Roger Lu ha scritto:
> The purpose of SVS is to help find the suitable voltages
> for DVFS. Therefore, if SVS bank voltages are concerned
> to be wrong, we can adjust SVS bank voltages by this patch.
>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Hello Roger,
I was thinking about what this patch is adding... and I have a few considerations.
It's nice to have a debugging mechanism to read the status and dump registers, as
that's very helpful when doing heavy debugging of the IP... but adding the
possibility to write a voltage offset may be very dangerous: think about the case
in which, either for misconfiguration, or for any other reason, the debugfs entry
that allows writing voffset becomes user-writable, or a user writes an impossibly
high voffset.
In case a very low (negative) voffset is entered, the platform would crash (denial
of service); if a very high voffset is entered, hardware damage may occur.
For this reason, there are two proposals:
1. If you want to keep the debugfs voffset write, please constrain the permissible
voffset to an acceptable range that at least makes it unlikely to damage the HW;
Moreover, since voffset write is a feature that would be used in very limited
debugging cases, I think that this should be implemented over a build-time
configuration barrier... something like CONFIG_MTK_SVS_DEBUG_ALLOW_WRITE, or
similar;
2. Since it's very unlikely for someone to really play that much with a voltage
offset during runtime, and since this looks like something very machine specific
(perhaps addressing board-specific quirks?), I would suggest to add this as a
device-tree parameter instead, such as "mediatek,svs-voffset", as it is indeed
possible to specify both positive or negative values in DT.
I would prefer proposal 2, as it looks generally cleaner and way less risky.
Regards,
Angelo
next prev parent reply other threads:[~2022-01-31 11:12 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 3:39 [PATCH v22 0/7] soc: mediatek: SVS: introduce MTK SVS engine Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` [PATCH v22 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-02-01 23:40 ` Rob Herring
2022-02-01 23:40 ` Rob Herring
2022-02-01 23:40 ` Rob Herring
2022-02-07 6:24 ` Roger Lu
2022-02-07 6:24 ` Roger Lu
2022-02-07 6:24 ` Roger Lu
2022-02-15 9:51 ` Roger Lu
2022-02-15 9:51 ` Roger Lu
2022-02-15 9:51 ` Roger Lu
2022-01-27 3:39 ` [PATCH v22 2/7] arm64: dts: mt8183: add svs device information Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` [PATCH v22 3/7] soc: mediatek: SVS: introduce MTK SVS engine Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-31 10:42 ` AngeloGioacchino Del Regno
2022-01-31 10:42 ` AngeloGioacchino Del Regno
2022-01-31 10:42 ` AngeloGioacchino Del Regno
2022-01-27 3:39 ` [PATCH v22 4/7] soc: mediatek: SVS: add monitor mode Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-31 10:44 ` AngeloGioacchino Del Regno
2022-01-31 10:44 ` AngeloGioacchino Del Regno
2022-01-31 10:44 ` AngeloGioacchino Del Regno
2022-01-27 3:39 ` [PATCH v22 5/7] soc: mediatek: SVS: add debug commands Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-31 11:11 ` AngeloGioacchino Del Regno [this message]
2022-01-31 11:11 ` AngeloGioacchino Del Regno
2022-01-31 11:11 ` AngeloGioacchino Del Regno
2022-02-15 9:08 ` Roger Lu
2022-02-15 9:08 ` Roger Lu
2022-02-15 9:08 ` Roger Lu
2022-02-15 9:10 ` AngeloGioacchino Del Regno
2022-02-15 9:10 ` AngeloGioacchino Del Regno
2022-02-15 9:10 ` AngeloGioacchino Del Regno
2022-01-27 3:39 ` [PATCH v22 6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` [PATCH v22 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-27 3:39 ` Roger Lu
2022-01-31 10:56 ` AngeloGioacchino Del Regno
2022-01-31 10:56 ` AngeloGioacchino Del Regno
2022-01-31 10:56 ` AngeloGioacchino Del Regno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0846872b-03da-ee5d-6a9d-e6c9fa754191@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=Angus.Lin@mediatek.com \
--cc=Charles.Yang@mediatek.com \
--cc=HenryC.Chen@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=Xiaoqing.Liu@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=drinkcat@google.com \
--cc=eballetbo@gmail.com \
--cc=fan.chen@mediatek.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=nm@ti.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=roger.lu@mediatek.com \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.