All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.