[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1bc18dc60615e3eda0afe35a597b77dfd05ce010.camel@mediatek.com>
Date: Thu, 14 Aug 2025 03:27:34 +0000
From: Liju-clr Chen (陳麗如)
<Liju-clr.Chen@...iatek.com>
To: "corbet@....net" <corbet@....net>, "krzk@...nel.org" <krzk@...nel.org>,
Ze-yu Wang (王澤宇) <Ze-yu.Wang@...iatek.com>,
"catalin.marinas@....com" <catalin.marinas@....com>, "rostedt@...dmis.org"
<rostedt@...dmis.org>, "robh@...nel.org" <robh@...nel.org>,
"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
"mhiramat@...nel.org" <mhiramat@...nel.org>, "krzk+dt@...nel.org"
<krzk+dt@...nel.org>, "will@...nel.org" <will@...nel.org>,
Yingshiuan Pan (潘穎軒)
<Yingshiuan.Pan@...iatek.com>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
"richardcochran@...il.com" <richardcochran@...il.com>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
CC: Shawn Hsiao (蕭志祥) <shawn.hsiao@...iatek.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Kevenny Hsieh (謝宜芸)
<Kevenny.Hsieh@...iatek.com>, "linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, Chi-shen Yeh (葉奇軒)
<Chi-shen.Yeh@...iatek.com>, "linux-trace-kernel@...r.kernel.org"
<linux-trace-kernel@...r.kernel.org>,
PeiLun Suei (隋培倫) <PeiLun.Suei@...iatek.com>
Subject: Re: [PATCH v13 04/25] virt: geniezone: Add GenieZone hypervisor
driver
On Tue, 2025-08-12 at 09:32 +0200, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On 12/08/2025 09:04, Liju-clr Chen (陳麗如) wrote:
> > we have guarded the gzvm driver with the CONFIG_MTK_GZVM Kconfig
> > option. This ensures the code is only compiled and active on
> > selected
> > platforms, and will not affect other users or systems.
>
> That is simply not true, since it will be enabled in defconfig in
> EVERY
> platform. Look up approach of single kernel and single image.
>
> Best regards,
> Krzysztof
Hi Krzysztof,
Thank you for explaining why the Kconfig option cannot prevent
polluting all systems due to the single kernel approach.
As you mentioned, using Kconfig cannot solve the issue of polluting all
systems, so probing directly is not recommended.
The other method I know is to use a DT node, but the community does not
accept DT nodes without real hardware resources.
Currently, these are the only two methods I am aware of. I will
continue to look for other possible solutions, and any suggestions
would be appreciated.
Thank you again for your feedback.
Best Regards,
Liju-clr Chen
Powered by blists - more mailing lists