All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Lu <roger.lu@mediatek.com>
To: AngeloGioacchino Del Regno 
	<angelogioacchino.delregno@collabora.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: Tue, 15 Feb 2022 17:08:45 +0800	[thread overview]
Message-ID: <eb4a903b90020e8220768e9bb674b9de477006e3.camel@mediatek.com> (raw)
In-Reply-To: <0846872b-03da-ee5d-6a9d-e6c9fa754191@collabora.com>

Hi AngeloGioacchino,

Excuse me for the late reply.

On Mon, 2022-01-31 at 12:11 +0100, AngeloGioacchino Del Regno wrote:
> 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.

Thanks for raising the considerations and give these great suggestions for us to
think about. Since these voffset read/write commands are used seldomly, we
decide to remove them for better system security.

> 
> Regards,
> Angelo


WARNING: multiple messages have this Message-ID (diff)
From: Roger Lu <roger.lu@mediatek.com>
To: AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.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: Tue, 15 Feb 2022 17:08:45 +0800	[thread overview]
Message-ID: <eb4a903b90020e8220768e9bb674b9de477006e3.camel@mediatek.com> (raw)
In-Reply-To: <0846872b-03da-ee5d-6a9d-e6c9fa754191@collabora.com>

Hi AngeloGioacchino,

Excuse me for the late reply.

On Mon, 2022-01-31 at 12:11 +0100, AngeloGioacchino Del Regno wrote:
> 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.

Thanks for raising the considerations and give these great suggestions for us to
think about. Since these voffset read/write commands are used seldomly, we
decide to remove them for better system security.

> 
> 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: Roger Lu <roger.lu@mediatek.com>
To: AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.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: Tue, 15 Feb 2022 17:08:45 +0800	[thread overview]
Message-ID: <eb4a903b90020e8220768e9bb674b9de477006e3.camel@mediatek.com> (raw)
In-Reply-To: <0846872b-03da-ee5d-6a9d-e6c9fa754191@collabora.com>

Hi AngeloGioacchino,

Excuse me for the late reply.

On Mon, 2022-01-31 at 12:11 +0100, AngeloGioacchino Del Regno wrote:
> 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.

Thanks for raising the considerations and give these great suggestions for us to
think about. Since these voffset read/write commands are used seldomly, we
decide to remove them for better system security.

> 
> Regards,
> Angelo


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-02-15  9:08 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
2022-01-31 11:11     ` AngeloGioacchino Del Regno
2022-01-31 11:11     ` AngeloGioacchino Del Regno
2022-02-15  9:08     ` Roger Lu [this message]
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=eb4a903b90020e8220768e9bb674b9de477006e3.camel@mediatek.com \
    --to=roger.lu@mediatek.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=angelogioacchino.delregno@collabora.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=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.